Re: [Xen-devel] [PATCH] x86/vpmu: Add get/put_vpmu() and VPMU_ENABLED

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 02/17/2017 10:58 AM, Andrew Cooper wrote:
> On 17/02/17 14:17, Boris Ostrovsky wrote:
> > On 02/17/2017 03:27 AM, Jan Beulich wrote:
> > > > > > On 16.02.17 at 19:09, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > > > On 02/16/2017 12:09 PM, Andrew Cooper wrote:
> > > > > Second, if it is available, has the toolstack chosen to allow the
> > > > > domain
> > > > > to use it.  This should determine whether features/information are
> > > > > visible in CPUID.
> > > > You mean if toolstack masks out leaf 0xa on Intel? I chould check this
> > > > in get_vpmu(). Is this information available by the time
> > > > vcpu_initialise() runs?
> > > You shouldn't rely on this, even if it happened to be that way
> > > right now. Instead you'd have to adjust accordingly when CPUID
> > > info gets updated by the tool stack (update_domain_cpuid_info()
> > > as the root hook point).
> > Right, that's what I was going to do --- destroy VPMU if CPUID
> > indicates no support.
> From a CPUID side of things, the way I would eventually like things to
> work is this:
>
> * Hardware support and Xen command line options influence the visibility
> of vPMU bits in {hvm,pv}_max_policy.
>
> * Using *_max_policy and domain.cfg settings, a toolstack opts in to
> allowing vPMU by setting vPMU details in the domains policy.
>
> The eventual plan for toolstack API will be that the entire policy is
> got/set at once (rather than individual leaves as it currently exists).
> Xen audits the toolstacks choice against {hvm,pv}_max_policy, rejecting
> the update wholesale if it is bad.
>
> Then, Xen will compare the old and proposed new policies to see what has
> changed, and use this to enable subsystems for a domain (either
> passively by having the subsystem rely on CPUID values, or actively by
> calling into the subsystem to initialise things).  nested-virt was my
> main target here, but vPMU looks like it fits into the same category, as
> well as some of the debugging facilities such as LBR etc.
>
>
> I realise that this infrastructure doesn't all exist yet,  but it would
> be helpful if your fix can easily be turned into API matching the above,
> when I complete the missing CPUID pieces.

Currently, since we don't know whether the toolstack will be updating 
leaf 0xa, we have to initialize VPMU at VCPU initialization time and 
then possibly destroy it if CPUID update does come in.
When your suggested infrastructure is in place it we can defer VPMU 
initialization until after the policy has been loaded. And I think it 
should be a pretty easy conversion.
Let me send what I have now.

-boris

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