[SeaBIOS] [PATCH v3 2/2] QEMU fw_cfg: Add command to write back address of file

[Ben Warren]

Hi Laszlo
> On Feb 9, 2017, at 12:24 AM, Laszlo Ersek <lersek at redhat.com> wrote:
> 
> On 02/09/17 09:17, Laszlo Ersek wrote:
>> Ben,
>> 
>> On 02/05/17 18:09, ben at skyportsystems.com wrote:
>>> From: Ben Warren <ben at skyportsystems.com>
>>> 
>>> This command is similar to ADD_POINTER, but instead of patching
>>> memory, it writes the pointer back to QEMU over the DMA interface.
>>> 
>>> Signed-off-by: Ben Warren <ben at skyportsystems.com>
>>> ---
>>> src/fw/romfile_loader.c | 37 +++++++++++++++++++++++++++++++++++++
>>> src/fw/romfile_loader.h | 16 ++++++++++------
>>> 2 files changed, 47 insertions(+), 6 deletions(-)
>> 
>> while working on the OVMF patches for WRITE_POINTER, something else
>> occurred to me.
>> 
>> As I mentioned in the QEMU thread,
>> 
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg428495.html
>> 
>> the VMGENID device (or more generally, each device that produces
>> WRITE_POINTER command(s)) should have a reset handler that makes the
>> device forget the GPA(s) that the firmware communicated to it, via
>> WRITE_POINTER. This is because after system reset, all earlier GPAs
>> become meaningless.
>> 
>> What I want to mention here is the corollary to the above. ACPI S3
>> resume is basically a reset, but the GPAs remain valid, because system
>> memory is preserved. Therefore, at S3 resume, the guest firmware has to
>> replay all the WRITE_POINTER commands. The QEMU reset handler will
>> forcibly forget about the GPAs (which is correct), so the firmware has
>> to re-store them.
> 
> ... By that I don't necessarily mean to re-run the exact same
> linker-loader logic; it should be okay to save the *results* of those
> operations in a simpler array (that is, write exactly what values to
> what fw_cfg files at what offsets).
> 
> And, you can detect whether this is needed at all, the
> "etc/system-states" fw_cfg file can be used to see if ACPI S3 is enabled
> or disabled in QEMU. (Please grep QEMU for "disable_s3" and
> "etc/system-states".)
> 
I’ve made some changes to SeaBIOS that I believe should do this, but don’t really know how to test it.
Here’s what I’ve tried:
	• Instrumented QEMU to print a message when a fw_cfg write comes from the guest
	• called QEMU with the additional arguments "-global PIIX4_PM.disable_s3=0”.  Note that my machine type is pc-i440fx-2.8
	• Booted a Linux guest.  Once logged in, typed “pm-suspend”
	• Noted the following in the QEMU monitor:
		• (QEMU) 
		{u'timestamp': {u'seconds': 1487310498, u'microseconds': 971046}, u'event': u'SUSPEND’}
	• Woke the guest up from QEMU monitor:
	• (QEMU) system_wakeup
          {"return": {}}
          (QEMU) 
          {u'timestamp': {u'seconds': 1487310558, u'microseconds': 135357}, u'event': u'WAKEUP’}

But didn’t see the fw_cfg getting written.  I don’t understand the ACPI states well enough to know if the above sequence is exercising S3, so don’t really want to spend more effort without knowing I’m doing the right thing.

Any advice you can give here would be great.

I’m posting the patch set without this change so that at least we have something, although I’d really like to get this S3 resume code in place too.

—Ben

<snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/seabios/attachments/20170216/99aa851b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3583 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/seabios/attachments/20170216/99aa851b/attachment.p7s>