>>> On 26.05.17 at 19:03, <andrew.coop...@citrix.com> 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.
DYM EFER.LMA here?
> 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.
>
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
I would like to get clarification from Huaitong, however, on the
reason for the original change: According to the reasoning here,
it shouldn't have been an observed failure of some kind, but
merely the thinking that something may be wrong (but really
wasn't).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
