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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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