Re: [PATCH] x86: Allow PV guest set X86_CR4_PCE flag

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 08/10/2015 11:02 AM, Andrew Cooper wrote:
> On 10/08/15 15:49, Boris Ostrovsky wrote:
>>
>> On 08/10/2015 10:37 AM, Andrew Cooper wrote:
>>> On 10/08/15 15:27, Boris Ostrovsky wrote:
>>>> With added PV support for VPMU, guests may legitimately decide to set
>>>> CR4's PCE flag. We should allow this when VPMU is enabled.
>>>>
>>>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>> Why?  Even a PV guest using VPMU should know that it doesn't actually
>>> control CR4.PCE
>>>
>>> All this (appears to) end up doing is putting PCE into the "allow but
>>> ignore" mask.
>> Yes, that's what I wanted to do.
>>
>>> How about this (not even compile tested) which is a rather shorter way
>>> of doing the same thing:
>> We could do this too but I thought that if we have VPMU off there is
>> no reason to allow this bit to be set (quietly).
> Adding the bit to this mask doesn't allow the guest to play with it.
> Xen never sets CR4.PCE.
>
> The question is whether warning about the guest attempting to set it is
> worthwhile or not.  We have no rdpmc support in emulate_privileged_op()
> so any attempt to use it will result in a #UD being injected.

That's because (at least on Linux) we turn it into rdmsr.

Actually, let's forget this patch. Given what I just said above, I think 
it's better to fix this on Linux side and just clear PCE bit in 
xen_write_cr4().

-boris

>
>> (There is no cpu_has_pce, we'd use cpu_has_arch_perfmon on Intel and
>> do this unconditionally on AMD)
> It could trivially be added.  The salient piece of information is
> whether the hardware would support setting CR4.PCE, not whether any of
> the interesting features which come with it are present.
>
> ~Andrew