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