RE: [Xen-devel] [PATCH 0/4] HVM Virtual S3

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser
>Sent: 2007年5月17日 6:34
>
>Oh, I see there is device state to be reset in QEMU. Emulating the port
>access in QEMU makes sense then, but I wonder if rather than adding
>an extra
>hypercall command we could emulate it in both Xen and QEMU: Xen
>emulates the
>instruction, resets state and triggers domain shutdown, then passes the
>port
>access up to QEMU so it does its thing also. We do this emulate-in-both
>for
>other things already (e.g., the CMOS index register I believe).
>
> -- Keir
>

I doubt whether this will bring some tricky issues if Qemu happens 
to inject some event after Xen's reset but before Qemu's reset. If 
that event results a stale pending interrupt after Xen resets vPIC or 
vIOAPIC, will that result a spurious interrupt after HVM is resumed? 
By current style, Qemu first reset all virtual devices and thus stop 
interrupt sources. Then it's safe to let Xen do a full reset subsequently.

Also normally the reason to put Qemu logic into Xen is for performance. For 
virtual S3 interception, it doesn't matter since only resume time is 
the concern.

Just doubt whether it's worthy of such split anyway. :-)

Of course above concern is only for one path per your on-going 
discussion. For the other path on top of save/restore, it's always 
OK since domain is re-created.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel