On Mon, 20 Feb 2017 14:28:11 +0100 Laszlo Ersek <ler...@redhat.com> wrote:
> On 02/20/17 14:13, Igor Mammedov wrote: > > On Mon, 20 Feb 2017 12:38:06 +0100 > > Laszlo Ersek <ler...@redhat.com> wrote: [...] > >> Interesting! I hope Igor can double-check this! > > I've retested v7, and it reliably fails (vmgenid_wait doesn't see change) > > then I tested v8(qemu) + (seabios v5/v4) with the same steps as before > > and it appears to work as expected, i.e. vmgenid_wait reports GUID > > change after executing 'continue' monitor command so something > > has been fixed in v8. > > Yes, I know what. Please see item (2) in this reply of mine, for v7 1/8: > > msgid: <9e222b4c-c05d-8fd0-6c55-4b2e52cab...@redhat.com> > URL: https://www.mail-archive.com/qemu-devel@nongnu.org/msg430440.html > > With that copy/paste bug in the code, the "src_offset" field of > WRITE_POINTER was not populated correctly. The BIOS would carry that out > faithfully, of course, but then later QEMU would write the fresh GUID to > an incorrect offset in the guest firmware allocated area -- the offset > wouldn't match the AML code (ADDR method), so the guest OS wouldn't see > the change. > > > If you scroll to the end of my message linked above, I wrote -- again, > for v7 --: > > I also tested this series (with the assignment under (2) fixed up, > of course), as documented earlier in > <https://www.mail-archive.com/qemu-devel@nongnu.org/msg430075.html> > (msgid <678c203f-3768-7e65-6e48-6729473b6...@redhat.com>). > > Hence, with (1) and (2) fixed, you can also add > > Tested-by: Laszlo Ersek <ler...@redhat.com> > > In other words, my positive testing for v7 was conditional on my *local* > (but reported, suggested) fix for bug (2) in v7 1/8. And that issue has > been fixed in v8. > > ... So, I guess we're all OK now. Can you confirm please? Confirmed > > Thanks! > Laszlo [...]