WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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>