On 02/17/17 14:05, Igor Mammedov wrote: > On Fri, 17 Feb 2017 13:50:40 +0100 > Laszlo Ersek <ler...@redhat.com> wrote: > >> CC Dave >> >> On 02/17/17 11:43, Igor Mammedov wrote: >>> On Thu, 16 Feb 2017 15:15:36 -0800 >>> b...@skyportsystems.com wrote: >>> >>>> From: Ben Warren <b...@skyportsystems.com> >>>> >>>> This implements the VM Generation ID feature by passing a 128-bit >>>> GUID to the guest via a fw_cfg blob. >>>> Any time the GUID changes, an ACPI notify event is sent to the guest >>>> >>>> The user interface is a simple device with one parameter: >>>> - guid (string, must be "auto" or in UUID format >>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) >>> I've given it some testing with WS2012R2 and v4 patches for Seabios, >>> >>> Windows is able to read initial GUID allocation and writeback >>> seems to work somehow: >>> >>> (qemu) info vm-generation-id >>> c109c09b-0e8b-42d5-9b33-8409c9dcd16c >>> >>> vmgenid client in Windows reads it as 2 following 64bit integers: >>> 42d50e8bc109c09b:6cd1dcc90984339b >>> >>> However update path/restore from snapshot doesn't >>> here is as I've tested it: >>> >>> qemu-system-x86_64 -device vmgenid,id=testvgid,guid=auto -monitor stdio >>> (qemu) info vm-generation-id >>> c109c09b-0e8b-42d5-9b33-8409c9dcd16c >>> (qemu) stop >>> (qemu) migrate "exec:gzip -c > STATEFILE.gz" >>> (qemu) quit >>> >>> qemu-system-x86_64 -device vmgenid,id=testvgid,guid=auto -monitor stdio >>> -incoming "exec: gzip -c -d STATEFILE.gz" >>> (qemu) info vm-generation-id >>> 28b587fa-991b-4267-80d7-9cf28b746fe9 >>> >>> guest >>> 1. doesn't get GPE notification that it must receive >>> 2. vmgenid client in Windows reads the same value >>> 42d50e8bc109c09b:6cd1dcc90984339b >> >> Hmmm, I wonder if we need something like this, in vmgenid_post_load(): >> >> commit 90c647db8d59e47c9000affc0d81754eb346e939 >> Author: Dr. David Alan Gilbert <dgilb...@redhat.com> >> Date: Fri Apr 15 12:41:30 2016 +0100 >> >> Fix pflash migration >> >> with the idea being that in a single device's post_load callback, we >> shouldn't perform machine-wide actions (post_load is likely for fixing >> up the device itself). If machine-wide actions are necessary, we should >> temporarily register a "vm change state handler", and do the thing once >> that handler is called (when the machine has been loaded fully and is >> about to continue execution). >> >> Can you please try the attached patch on top? (Build tested only.) > it doesn't help
Thanks for trying! And, well, sh*t. :( I guess it's time to resurrect the monitor command (temporarily, for testing) so we can inject the SCI at will, without migration. I don't want to burden you unreasonably, so I'll make an effort to try that myself. Thanks! Laszlo
