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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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?

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