RE: [Xen-devel] expose MWAIT to dom0

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> 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
>> 
>> >>> On 15.08.11 at 10:09, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>> >> >>> On 15.08.11 at 07:35, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> >> > It's unlikely to make into upstream, and also get lost in
>> >> > into some distro such as SLES11.
>> >>
>> >> We can certainly fix it there.
>> >>
>> >
>> > that'd be great. I/O method has observable impact on power efficiency,
>> > and the fix would be very welcomed. :-)
>> 
>> While the change is simple to do and works, I'm somewhat concerned
> 
> Current change mentioned above is not safe, which always enables mwait
> support w/o knowledge about underlying presence. But new processors

Not following you here: If I execute a "real" cpuid instruction, I will know
whether mwait is "present".

> all have mwait support, so this may not be big problem.
> 
>> 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
_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).

Jan


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