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

RE: [Xen-devel] expose MWAIT to dom0

>>> On 19.08.11 at 03:31, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> OK, to avoid the regression, if it's really cared, then we may change Xen 
> to support entering C-state by mwait with interrupt enabled.

I don't think that's worth it.

> But the next question is whether it's really worthy of enabling Xen PM 
> such way:
>       - I think native Linux only supports mwait with break-on-interrupt
> extension too. You may confirm on such machines which I think should 
> have no C2/C3 available. It's less likely for a customer to try PM on a 
> platform where native Linux fails to do that

Looking at the code, I can't see why Linux wouldn't use the I/O method
in this case instead.

>       - using mwait with interrupt enabled lacks the trace capability, 
> while w/o trace I don't think any customer would enable Xen PM w/o a
> verification process.
> Another approach, if we really want to keep original I/O style, is to
> reveal Xen's mwait related conditions in shared info page, say a simple
> flag to indicate whether mwait bit should be set by pvops cpuid hook.
> Xen will check mwait extension earlier before dom0 is launched, instead
> of current point where dom0 registers cx info. This way there's no Xen
> implementation detail encoded in dom0, while concerned regression 
> could be removed.

The concept sounds reasonable, just that the shared info page probably
isn't the right mechanism (after all this is Dom0-only information that
we want to expose). A new platform sub-hypercall would probably be
the better route.


Xen-devel mailing list



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