[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Yu, Ke" <ke.yu@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 16 May 2007 23:33:51 +0100
  • Delivery-date: Wed, 16 May 2007 15:30:12 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceX2gAl4h+XcEYPRxOJnM8JUiP1/QAK20w3AAE2ZE8=
  • Thread-topic: [Xen-devel] [PATCH 0/4] HVM Virtual S3

On 16/5/07 22:59, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

>> The main idea is:
>> - emulate ACPI PM1A control resiger in QEMU to capture guest S3 request
>> - when QEMU capture guest S3 request, it call hypercall to trap to Xen
> 
> So why emulate this register in QEMU at all, rather than directly in Xen?
> Xen already knows the address of the pm1a block of ports because it emulates
> the pmtimer.

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.