Re: [Xen-devel] HVMlite ABI specification DRAFT B + implementation outline

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 17:17, <david.vrabel@xxxxxxxxxx> wrote:
> On 09/02/16 16:15, Jan Beulich wrote:
>>>>> On 09.02.16 at 16:06, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>> On Tue, 9 Feb 2016, Jan Beulich wrote:
>>>> Will STAO be sufficient for everything that may need customization?
>>>> I'm particularly worried about processor related methods in DSDT or
>>>> SSDT, which - if we're really meaning to do as you say - would need
>>>> to be limited (or extended) to the number of vCPU-s Dom0 gets.
>>>> What's even less clear to me is how you mean to deal with P-, C-,
>>>> and (once supported) T-state management for CPUs which don't
>>>> have a vCPU equivalent in Dom0.
>>>
>>> It is possible to use the STAO to hide entire objects, including
>>> processors, from the DSDT, which should be good enough to prevent dom0
>>> from calling any of the processor related methods you are referreing to.
>>> Then we can let Xen do cpuidle and cpufreq as it is already doing.
>>>
>>> Would that work? Or do we still need Dom0 to call any ACPI methods for
>>> power management?
>> 
>> We want two things at once here, which afaict can't possibly work:
>> On one hand we want Dom0 to only see ACPI objects corresponding
>> to its own vCPU-s. Otoh we need Dom0 to see all objects, in order
>> to propagate respective information to Xen.
> 
> Could dom0 query Xen for the machine ACPI tables via a hypercall?

That would certainly be doable, but what would it do then with
these tables? Loading them just like other tables is not an option,
as that would result in a mess of name space collisions. And I don't
think abstracting ACPI CA to be able to deal with two independent
sets of tables would be very welcome on the Linux or ACPI side...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel