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

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

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Yu, Ke" <ke.yu@xxxxxxxxx>
  • Date: Thu, 17 May 2007 10:28:26 +0800
  • Delivery-date: Wed, 16 May 2007 19:26:55 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceX2gAl4h+XcEYPRxOJnM8JUiP1/QAK20w3AAE2ZE8ABk5IIA==
  • Thread-topic: [Xen-devel] [PATCH 0/4] HVM Virtual S3

Keir Fraser  wrote on 6:34:
> 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

Yes. that's a good idea. The only disadvantage is that it scatter the
ACPI register logic from QEMU, and make it a little bit harder for
maintaince. But it is a acceptable tradeoff. 

Best Regards

Xen-devel mailing list



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