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] expose MWAIT to dom0

>>> On 19.08.11 at 10:34, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>  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);
> 

Right, this precludes the use of MWAIT, but it doesn't preclude using
the I/O method.

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

Yet another idea - why don't we simply pass the buffer passed to
arch_acpi_set_pdc_bits() down to Xen, rather than fiddling with the
bits in Dom0? That would at once allow to not set ACPI_PDC_T_FFH
(which I don't think Xen really supports at present).

Or really, depending on who controls what, the P, C, and T bits should
be set by either Dom0 or Xen (so e.g. let Dom0 do what it currently
does, and then let Xen override the bits it ought to control).

Jan


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