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