On Monday 23 March 2009, Tian, Kevin wrote: > >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? IMO, no, it isn't. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
