From: Markus Armbruster <armbru@redhat.com>
To: Stephen Checkoway <stephen.checkoway@oberlin.edu>
Cc: "Laszlo Ersek" <lersek@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Testing sysbus devices
Date: Fri, 22 Feb 2019 08:42:10 +0100 [thread overview]
Message-ID: <877edsqnfx.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <FBD3F2EA-638A-4B52-826B-7307B1D821C9@oberlin.edu> (Stephen Checkoway's message of "Thu, 21 Feb 2019 14:57:38 -0500")
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.
> 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).
Can you tell us a bit more about what exactly can go wrong?
next prev parent reply other threads:[~2019-02-22 7:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 6:07 [Qemu-devel] Testing sysbus devices Stephen Checkoway
2019-02-18 13:43 ` Thomas Huth
2019-02-18 16:02 ` Stephen Checkoway
2019-02-18 16:38 ` Thomas Huth
2019-02-18 18:08 ` Markus Armbruster
2019-02-18 18:31 ` Stephen Checkoway
2019-02-19 6:09 ` Markus Armbruster
2019-02-19 14:42 ` Stephen Checkoway
2019-02-19 15:28 ` Markus Armbruster
2019-02-19 16:00 ` Stephen Checkoway
2019-02-19 17:55 ` Markus Armbruster
2019-02-20 8:55 ` Laszlo Ersek
2019-02-20 10:14 ` Markus Armbruster
2019-02-21 19:57 ` Stephen Checkoway
2019-02-22 7:42 ` Markus Armbruster [this message]
2019-02-22 8:03 ` Laszlo Ersek
2019-02-22 13:31 ` Stephen Checkoway
2019-02-22 7:55 ` Laszlo Ersek
2019-02-22 13:35 ` Stephen Checkoway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877edsqnfx.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=lersek@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen.checkoway@oberlin.edu \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.