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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.02.16 at 17:26, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Tue, 9 Feb 2016, 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.
> 
> Having Dom0 see only objects corresponding to its own vCPU-s would of
> course be nicer from an architectural point of view. What exactly do we
> need to propagate from Dom0 to Xen? Can we get rid of those calls?

Not really, no. Or else - as said above - there wouldn't be any
P- or C-state management anymore.

Jan


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