RE: [Xen-devel] expose MWAIT to dom0

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Friday, August 19, 2011 4:11 PM
> 
> >>> 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.

acpi_processor_ffh_cstate_probe_cpu:
        /* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
        if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
            !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
                retval = -1;
                goto out;
        }

arch_acpi_set_pdc_bits:
        /*
         * If mwait/monitor is unsupported, C2/C3_FFH will be disabled
         */
        if (!cpu_has(c, X86_FEATURE_MWAIT))
                buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);

> 
> >     - 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.
> 

yes, that's a better choice.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel