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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

>
>
>> Which gets us to another point: Shouldn't
>> we disallow CPUID info updates after the guest started running?
>> Or do we mean to trust the tool stack to not do this if it doesn't
>> want to confuse a guest?
>
> I believe currently it's the latter. I don't see anything preventing
> CPUID update to a running guest (except for pausing it while the
> update is in progress).

This is on my TODO list longer than d->creation_finished has existed. 
The CPUID policy should be immutable even by the toolstack once the
guest is running.

~Andrew

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