Hi Laszlo
On Feb 9, 2017, at 12:24 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 02/09/17 09:17, Laszlo Ersek wrote:
Ben,

On 02/05/17 18:09, ben@skyportsystems.com wrote:
From: Ben Warren <ben@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@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>