qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Testing sysbus devices


From: Markus Armbruster
Subject: Re: [Qemu-devel] Testing sysbus devices
Date: Fri, 22 Feb 2019 08:42:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Stephen Checkoway <address@hidden> writes:

>> On Feb 20, 2019, at 03:55, Laszlo Ersek <address@hidden> wrote:
>> 
>> I would strongly prefer if the guest-side view wouldn't change at all.
>
> It sounds like sector protection isn't something you want and it's not

László is content with the status quo, but I'm not.

> something I currently need so unless that changes, I probably won't do
> anything with it.

Pity.

> My goal is merely to implement some missing flash functionality that I
> need to emulate some hardware that I have. My plan for doing this is
> to not change any defaults (except for a few bug fixes) while doing
> so. I'm happy for the qemu community to take as much or as little as
> it finds useful.

Understand.

> I'll send a patch series for review in the normal fashion, but if
> anyone wants to see my in-progress work, including tests, the diff is
> available here
> <https://github.com/qemu/qemu/compare/master...stevecheckoway:pflash02>.
>
> For my own edification, I'm curious how you're currently dealing with
> some regions of flash that are protected. I believe Markus mentioned
> using multiple flash devices. Are you overlapping the address ranges?

UEFI wants to store some persistent state in flash memory.  Real PCs
have a single flash chip with a suitable part configured to be writable
for firmware.

Since our flash device models can't do that (yet?), we worked around the
missing functionality by exposing two separate flash chips to guests,
one read-only, one writable for firmware.  The two are adjacent, no gap,
with the boundary aligned to 4KiB (page size).

Our track record for doing whatever real hardware does has been okay.
The track record for our own good-enough inventions less so.  I'm not
claiming this one is about to explode into our faces.  Still, I'd like
to clean it up if practical.  If not for PCs (say because complications
for OVMF render that less than practical), then at least for other, less
encumbered machines.

Would be nice if you could pitch in a bit.

Way, way more than you ever wanted to know on configuring flash for PCs:

    Subject: Configuring pflash devices for OVMF firmware
    Message-ID: <address@hidden>
    https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg06606.html

> The current pflash_cfi02.c code assumes, but doesn't check that both
> the total size of the chip as well as the size of each sector is a
> power of two. If you wanted say 7 MB of read/write flash and 1 MB of
> read-only flash, qemu might be willing to create a device with say 7
> MB of storage, but it will definitely misbehave. (I added a check for
> that here
> <https://github.com/qemu/qemu/compare/master...stevecheckoway:pflash02#diff-d33881bd0ef099e2f46ebd4797c653bcR738>.)

Awesome.  The magic setup code in hw/i386/pc_sysfw.c will happily create
any size that's a multiple of 4KiB.  The current sizes are 128KiB
writable (power of two, good) and 2MiB - 128KiB for read-only (very much
not a power of two, possibly bad).

Can you tell us a bit more about what exactly can go wrong?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]