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: Laszlo Ersek
Subject: Re: [Qemu-devel] Testing sysbus devices
Date: Fri, 22 Feb 2019 08:55:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 02/21/19 20:57, Stephen Checkoway wrote:
> 
> 
>> 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
> something I currently need so unless that changes, I probably won't do
> anything with it.
> 
> 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.
> 
> 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.

We aren't. The firmware has build-time constants that describe (a) what
GPA range stands for the varstore area (so that it is writeable at least
in SMM), and (b) what other range stands for the code area (which the
firmware never attempts to write). These ranges are adjacent.

> I believe Markus mentioned using multiple flash devices.

Yes. The firmware only has assumptions about GPA ranges, and
expectations about writeability. Originally it targeted a single r/w
chip, but it was possible to split that chip in two (one r/w and another
r/o) without the firmware noticing or caring.

> Are you overlapping the address ranges?

No, we're not.

> 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>.)

OVMF and the q35/i440fx boards use cfi01. The 4KB sector size is assumed
by both QEMU board code and OVMF. The 4KB sector size is not assumed (to
my knowledge) by cfi01.pflash device model code.

Regarding the full size of each cfi01.pflash chip, i440fx/q35 board code
determines that dynamically from the file size (the only requirement is
that the size be a multiple of the sector size). There is no assumption
in the device model. In OVMF, the assumed/expected full size is
hard-coded (build-time constant).

Thanks
Laszlo



reply via email to

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