From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: peter.maydell@linaro.org, Stefan Hajnoczi <stefanha@gmail.com>,
"Gabriel L. Somlo" <somlo@cmu.edu>,
qemu-devel@nongnu.org, jordan.l.justen@intel.com,
pbonzini@redhat.com, markmb@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM
Date: Tue, 27 Oct 2015 13:43:39 +0100 [thread overview]
Message-ID: <562F717B.6070501@redhat.com> (raw)
In-Reply-To: <1445944285.4397.37.camel@redhat.com>
On 10/27/15 12:11, Gerd Hoffmann wrote:
> Hi,
>
>>> My hypothesis (which I guess I'm volunteering to verify, unless we
>>> end up rejecting this immediately as a bad idea, for some reason that
>>> I have missed), is that current functionality wouldn't change, given
>>> the way existing callbacks work right now, and that we could run the
>>> callback each time a blob is *selected*, rather than hooking into the
>>> (dma/mmio/pio) read methods.
>>
>> Callback executed on first read only sounds okay to me, callback
>> executed on selection... hm... don't like it. :)
>
> Care to explain why?
>
> I think callback on selection would be better. Interface is more clear
> then, I don't like read having different behavior depending on hidden
> state (current offset).
> And in practice selection and read will always
> be called together,
This is what I think you cannot guarantee on the host side, without
auditing all guest code. The behavior of callbacks has been specified
under fw_cfg_add_file_callback(), in docs/specs/fw_cfg.txt, and guest
code is allowed to work off that.
> so there shouldn't be a difference in practice ...
I guess I have no choice but to audit all QemuFwCfgSelectItem calls in
edk2...
Right, here's what I've had in the back of my mind: see the
DetectSmbiosVersion() function in
"OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c". It selects
the key that belongs to the "etc/smbios/smbios-anchor" fw_cfg file, but
the switch statement right after it can jump to the "default" label, and
under that label *nothing* is read from fw_cfg.
This is valid guest code according to the current specs. Its behavior
would change (however obscurely) if there was a callback on the
"etc/smbios/smbios-anchor" file, and the callback was executed on
selection, not read.
... This one instance wouldn't be particularly hard to patch in edk2,
but in general our specs are useless if we don't stick to them.
Thanks
Laszlo
next prev parent reply other threads:[~2015-10-27 12:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 8:58 [Qemu-devel] QEMU fw_cfg DMA interface Marc Marí
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 0/5] " Marc Marí
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 1/5] fw_cfg: document fw_cfg_modify_iXX() update functions Marc Marí
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 2/5] fw_cfg DMA interface documentation Marc Marí
2015-09-18 15:15 ` Peter Maydell
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 3/5] Implement fw_cfg DMA interface Marc Marí
2015-09-18 15:31 ` Peter Maydell
2015-09-18 18:29 ` Kevin O'Connor
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 4/5] Enable fw_cfg DMA interface for ARM Marc Marí
2015-09-18 15:15 ` Peter Maydell
2015-09-18 19:33 ` Laszlo Ersek
2015-09-18 20:16 ` Laszlo Ersek
2015-09-18 20:24 ` Marc Marí
2015-09-18 23:10 ` Laszlo Ersek
2015-09-19 13:09 ` Marc Marí
2015-10-22 21:22 ` Gabriel L. Somlo
2015-10-26 10:48 ` Stefan Hajnoczi
2015-10-26 12:49 ` Gabriel L. Somlo
2015-10-26 13:38 ` Laszlo Ersek
2015-10-26 14:21 ` Gabriel L. Somlo
2015-10-27 11:11 ` Gerd Hoffmann
2015-10-27 12:43 ` Laszlo Ersek [this message]
2015-10-28 1:12 ` Gabriel L. Somlo
2015-10-28 10:42 ` Laszlo Ersek
2015-09-18 8:58 ` [Qemu-devel] [PATCH v3 5/5] Enable fw_cfg DMA interface for x86 Marc Marí
2015-09-18 10:58 ` Gerd Hoffmann
2015-09-18 15:12 ` Peter Maydell
2015-09-18 18:25 ` [Qemu-devel] [PATCH v3 0/5] fw_cfg DMA interface Kevin O'Connor
2015-09-18 19:14 ` Marc Marí
2015-09-18 22:47 ` Peter Maydell
2015-09-18 23:43 ` Kevin O'Connor
2015-09-19 9:48 ` Peter Maydell
2015-09-19 15:15 ` Kevin O'Connor
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=562F717B.6070501@redhat.com \
--to=lersek@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=kraxel@redhat.com \
--cc=markmb@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
--cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).