> From: Han, Huaitong
> Sent: Wednesday, May 31, 2017 4:15 PM
>
> On Wed, 2017-05-31 at 08:44 +0100, Andrew Cooper wrote:
> > On 31/05/2017 08:09, Han, Huaitong wrote:
> > > On Fri, 2017-05-26 at 18:03 +0100, Andrew Cooper wrote:
> > >> This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53.
> > >>
> > >> When determining Access Rights, Protection Keys only take effect when
> CR4.PKE
> > >> it set, and 4-level paging is active. All other circumstances (notibly,
> > >> 32bit
> > >> PAE paging) skip the Protection Key control mechanism.
> > >>
> > >> Therefore, we do not need to clear CR4.PKE behind the back of a guest
> which is
> > >> not using paging, as such a guest is necesserily running with EFER.LME
> > >> disabled.
> > > Yes, if EFER.LME = 0, Protection Keys would take no effect too, so it
> > > isn't necessary to clear CR4.PKE in non-paging mode.
> > >
> > >> The {RD,WR}PKRU instructions are specified as being legal for use in any
> > >> operating mode, but only if CR4.PKE is set. By clearing CR4.PKE behind
> the
> > >> back of an unpaged guest, these instructions yield #UD despite the guest
> > >> seeing PKE set if it reads CR4, and OSPKE being visible in CPUID.
> > > If CR4.PKE is cleared, OSPKE would be invisible at the same time. When
> > > guest does set CR4_PKE in non-paging mode, then CR4_PKE would be
> cleared
> > > in vmcs loading, so, OSPKE should be always invisible, and #UD should
> > > not be yielded too.
> >
> > Remember that for HVM guests, Xen calculates OSPKE in software; it never
> > comes from hardware, as CPUID is an automatic VMEXIT.
> >
> > The CPUID code uses the same source of information as a read from cr4,
> > so comes to the conclusion that OSPKE should be visible.
> >
> > Therefore, when the guest looks at CPUID, it sees OSPKE set even though
> > hardware would come to the opposite conclusion.
>
> Yes, I get the reason: the hw_cr4 is updated, but the guest_cr4 is not
> updated, so the OSPKE is visible.
>
> >
> > > Reviewed-by: Huaitong Han <huaitong....@intel.com>
> >
> > Does this stand despite the OSPKE issue?
> Yes, I have no comments now.
>
Acked-by: Kevin Tian <kevin.t...@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
