>>> On 21.08.11 at 07:26, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>> Sent: Friday, August 19, 2011 11:02 PM
>> > >> 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).
>> > >
>> > > _PDC is encoded in AML language, and requires an ACPI parser which
>> > > is one thing we avoid in Xen. If Xen want to override those bits, then
>> > > whole ACPI component needs move down to Xen too.
>> >
>> > No, I'm not saying the evaluation should be happening there. Below is
>> > a draft hypervisor patch (only compile tested so far).
>>
>> Attached a patch that actually works (with a minimal Dom0 addition).
>>
>
> yes, this change looks more straightforward. :-)
With that in, we still have more deficiencies compared to native Linux.
For one, we don't use mwait when ACPI doesn't tell us to, while Linux
does (in the intel_idle driver for deeper C-states, and for C1 also via
mwait_idle()). This is likely a bit more work, but it should be possible to
construct C-state information from CPUID leaf 5 (and, if valid, ignore
information passed down from Dom0), which would match intel_idle's
taking precedence over acpi_idle in Linux.
Second, if only C1 gets announced by ACPI, we end up not using it
because Dom0 simply neglects to let the hypervisor know. This is
because acpi_processor_get_power_info_cst() (back to at least
2.6.16) returns -EFAULT if less than two C-states were found. Simply
prefixing the check with "!processor_pm_external() && " fixes this
(but I don't know whether something similar could be done in Jeremy's
tree).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home