xen-devel
RE: [Xen-devel] Re: Paravirtualizing bits of acpi access
To: |
'Jeremy Fitzhardinge' <jeremy@xxxxxxxx>, "Rafael J. Wysocki" <rjw@xxxxxxx> |
Subject: |
RE: [Xen-devel] Re: Paravirtualizing bits of acpi access |
From: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx> |
Date: |
Mon, 23 Mar 2009 11:29:59 +0800 |
Accept-language: |
en-US |
Acceptlanguage: |
en-US |
Cc: |
"Brown, Len" <len.brown@xxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, "linux-acpi@xxxxxxxxxxxxxxx" <linux-acpi@xxxxxxxxxxxxxxx> |
Delivery-date: |
Sun, 22 Mar 2009 20:31:21 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<49C67054.7020603@xxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<49C484B7.20100@xxxxxxxx> <200903211810.53990.rjw@xxxxxxx> <49C5BDD8.1050605@xxxxxxxx> <200903221228.40181.rjw@xxxxxxx> <49C67054.7020603@xxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AcmrEL4OZ2cc/1FgSJS6Y7uLw5U9XAAUua1Q |
Thread-topic: |
[Xen-devel] Re: Paravirtualizing bits of acpi access |
>From: Jeremy Fitzhardinge
>Sent: Monday, March 23, 2009 1:08 AM
>
>Rafael J. Wysocki wrote:
>> On Sunday 22 March 2009, Jeremy Fitzhardinge wrote:
>>
>>> Rafael J. Wysocki wrote:
>>>
>>>> Well, why don't you implement the platform suspend
>operations for Xen?
>>>> I guess you don't want ACPI _PTS to be executed during
>suspend as well.
>>>>
>>>>
>>> I don't know. What's _PTS?
>>>
>>
>> It's an ACPI method called to prepare the platform to enter
>the sleep state
>> (the name stands for "prepare to sleep"). Executing it may
>affect the
>> hardware.
>>
>
>OK, that's what we want. Dom0 is the control domain which is
>responsible for the bulk of the hardware; Xen itself has very little
>hardware knowledge.
yes, Xen only takes care of several core system devices (pic,
ioapic, serial, timer sources) and cpus, and let dom0 control all
the rest. _PTS, imo, will not affect Xen controlled devices as
even on native those devices are suspended after _PTS. Also
Xen doesn't incorporate ACPI parser and thus can't evaluate any
ACPI method on its own.
>
>> I think you really should not execute any global ACPI
>methods to suspend a
>> guest, because that may affect the host. That's why I think
>it's better to
>> regard Xen as a platform and implement a separate set of
>suspend operations for
>> it.
>>
>
>In this case we're talking about the special privileged domain
>which can
>be considered to be on the "host" side of the line.
>
>That said, I'd be interested in looking at a suspend operations-based
>approach if you think its the right way to go. But I'm concerned that
>we'd end up with a big set of very similar-looking parallel functions
>just to deal with some difference in detail near the bottom. Can you
>give me a pointer to where this gets put together for acpi?
>
As Jeremy pointed out, dom0 is a special domain which cooperate
with Xen to fulfill the whole S3 sequence, i.e. dom0 still carries 99%
existing ACPI S3 flow, with several exceptions as below:
a) No need to prepare wakeup stub (since it's Xen to be first waken
up after resume), and no expectation that execution flow will be
resumed from its wakeup stub (context is resumed at hypercall
return)
b) No need to save/restore bsp context and gear to Xen by hypercall
at last step where originally hardware reg bits are written
And then Xen jumps in to finish remaining steps. From this angle,
Xen is not a completely new platform and, well, S3 is more like a
'S1' type from dom0's p.o.v with a different trigger method. Then is
it overkilled to introduce a new set of ops with 99% content
duplicated?
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
- Message not available
- Message not available
- Re: [Xen-devel] Re: Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
- RE: [Xen-devel] Re: Paravirtualizing bits of acpi access, Tian, Kevin
- Re: [Xen-devel] Re: Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
- RE: [Xen-devel] Re: Paravirtualizing bits of acpi access, Tian, Kevin
- Re: [Xen-devel] Re: Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
- Message not available
- Re: [Xen-devel] Re: Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
- RE: [Xen-devel] Re: Paravirtualizing bits of acpi access, Cihula, Joseph
- Message not available
- Re: [Xen-devel] Re: Paravirtualizing bits of acpi access, Jeremy Fitzhardinge
|
|
|