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

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





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@xxxxxxxxxx>
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


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


 


Rackspace

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