RE: [Xen-devel] expose MWAIT to dom0

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 16.08.11 at 08:53, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>> Sent: Tuesday, August 16, 2011 2:42 PM
>> 
>> >>> On 16.08.11 at 08:03, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>> >> Sent: Monday, August 15, 2011 6:29 PM
>> >>
>> >> that while improving the situation on CPUs that support the break-on-
>> >> interrupt extension to mwait, it would result in C2/C3 not being usable
>> >> at all on CPUs that don't (but support mwait in its simpler form and
>> >> have ACPI tables specifying FFH as address space id). Is that only a
>> >> theoretical concern (i.e. is there an implicit guarantee that for other
>> >> than C1 FFH wouldn't be specified without that extension being
>> >> available)? I thinks it's a practical one, or otherwise there wouldn't
>> >> be a point in removing the ACPI_PDC_C_C2C3_FFH bit prior to _PDC
>> >> evaluation.
>> >
>> > Yes, this is a practical one, though I don't know any box doing that. In 
> all
>> > the boxes I've been using so far, all the extensions are available. But
>> > since
>> > BIOS vendor may also impact the availability of CPUID bits, I think we
>> > should do it right by strictly conforming to theSDM. I.e. we need check
>> > CPUID leafs and then verify all Cx states propagated from dom0, instead
>> > of blindly following its info. Will work a patch for that.
>> 
>> You're getting it sort of wrong way round: What I don't want to do (but
>> seemingly being necessary) is mimic the decision logic the hypervisor
>> uses (i.e. require the break-on-interrupt extension for C2/C3 entering
>> through MWAIT) in Dom0 when deciding about the bits to pass to
> 
> break-on-interrupt is not a hard requirement to use MWAIT. Even when
> that extension is not available, MWAIT can be still used to enter C2/C3,
> just with interrupt enabled.

And that's why this implementation detail should be confined to the
hypervisor - Dom0 should not care about this if at all possible.

>> _PDC. That ought to be an implementation detail (subject to change)
>> in the hypervisor alone. The hypervisor itself, otoh, already properly
>> checks CPUID leaf 5 (and that's what might cause it to not use mwait
>> despite the bit in CPUID leaf 1 being set, which should be all Dom0
>> ought to look at for deciding whether to clear ACPI_PDC_C_C2C3_FFH).
>> 
> 
> I made a mistake, that currently CPUID leaf 5 is already checked in
> check_cx in hypervisor, so it should be sane. However I still fail to catch
> your real concern here. :/

If Dom0 finds (real) CPUID leaf 1 report MWAIT to be available, it
will (with the logic outlined above) call _PDC without clearing
ACPI_PDC_C_C2C3_FFH. If now the break-on-interrupt extension
is not present, but the address space ID for C2 or C3 is set to FFH,
then Xen (in acpi_processor_ffh_cstate_probe()) will reject the
Cx entry (and hence refrain from using the respective C-state),
whereas if Dom0 cleared ACPI_PDC_C_C2C3_FFH in that case,
firmware would (normally) have converted the address space ID to
SYSTEM_IO, and hence Xen would have decided to use C2/C3 with
the SYSIO entry method.

So this is only acceptable if there are *no* production CPUs of any
vendor that would support MWAIT without the break-on-interrupt
extension.

Jan


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