[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest



> On 14/02/17 02:19, Luwei Kang wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in guest.
> 
> Sorry for breaking this.  However ...
> 
> > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index
> > e0a387e..b63c5d8 100644
> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -713,8 +713,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
> > struct cpuid_leaf *res)
> >              }
> >          }
> >
> > -        if ( vpmu_enabled(curr) &&
> > -             vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> > +        if ( opt_vpmu_enabled && boot_cpu_has(X86_FEATURE_DS) )
> 
> ... this is overly general.  The visibility of these flags must be per 
> domain, and not globally like this.
> 
> In particular, XENPMU_MODE_ALL needs to expose PMU to dom0, but hide it from 
> all other domains, while even in the
> XENPMU_MODE_SELF case, only domains explicitly configured with PMU should see 
> it (as it generally unsafe to migrate with).
> 
> Longterm (with the inclusion of the CPUID improvements), my plan was to have 
> PMU available in the max policy but hidden in the
> default policy, which requires the toolstack to explicitly opt in for 
> domains.  It would opt in/out by setting the version field in guests
> CPUID policy and the other feature bits.
> 
Get it. Thanks for your explanation.

Thanks,
Luwei Kang

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.