Re: [Qemu-devel] Testing sysbus devices

[Laszlo Ersek <lersek@redhat.com>]

On 02/22/19 08:42, Markus Armbruster wrote:
> Stephen Checkoway <stephen.checkoway@oberlin.edu> writes:
> 
>>> On Feb 20, 2019, at 03:55, Laszlo Ersek <lersek@redhat.com> 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.

I think that's an accurate description. It means that I don't personally
pursue cleaning up this stuff. Obviously I'm also not trying to prevent
a cleanup! The only things I'd like to prevent are (a) regressions, (b)
introducing a version dependency between QEMU and OVMF in this area.

In the past we've dealt with similar issues via feature negotiation, as
long as the feature can be dynamically configured in the guest.
Unfortunately, pflash size / structure are one set of things that the
firmware can't configure dynamically.

>> 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: <87y378n5iy.fsf@dusky.pond.sub.org>
>     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).

Correct, wrt. the images shipped in Fedora. The upstream edk2/OVMF
default (also used in RHEL) is 528KB + 3568KB = 4MB. Upstream also
supports building for 128KB + 896KB = 1MB.

Thanks!
Laszlo

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