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