Re: [Qemu-devel] [PATCH v3 0/3] target-i386: add memory protection-key support

2015-12-04 Thread Eduardo Habkost
On Wed, Nov 18, 2015 at 10:20:14AM +0800, Huaitong Han wrote:
> Changes in v3:
> *Fix cpuid_7_0_ecx_feature_name error.
> 
> Changes in v2:
> *Fix memcpy error for xsave state.
> *Fix TCG_7_0_ECX_FEATURES to 0.
> *Make subjects more readable.
> 
> The protection-key feature provides an additional mechanism by which IA-32e
> paging controls access to usermode addresses.
> 
> Hardware support for protection keys for user pages is enumerated with CPUID
> feature flag CPUID.7.0.ECX[3]:PKU. Software support is CPUID.7.0.ECX[4]:OSPKE
> with the setting of CR4.PKE(bit 22).
> 
> The PKRU register is XSAVE-managed state CPUID.D.0.EAX[9], the size of XSAVE
> state component for PKRU is 8 bytes, the offset is 0xa80.
> 
> The specification of Protection Keys can be found at SDM (4.6.2, volume 3)
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf.

Reviewed-by: Eduardo Habkost 

The patches were squashed together and queued in x86-next branch
for 2.6.

> 
> Huaitong Han (3):
>   target-i386: add pkeys support for cpuid handling
>   target-i386: add pkeys support for xsave state handling
>   target-i386: add pkeys support for vm migration
> 
>  target-i386/cpu.c | 23 ++-
>  target-i386/cpu.h |  7 +++
>  target-i386/kvm.c |  3 +++
>  target-i386/machine.c | 23 +++
>  4 files changed, 55 insertions(+), 1 deletion(-)
> 
> -- 
> 2.4.3
> 
> 

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH v3 0/3] target-i386: add memory protection-key support

2015-11-18 Thread Eduardo Habkost
On Wed, Nov 18, 2015 at 10:20:14AM +0800, Huaitong Han wrote:
> Changes in v3:
> *Fix cpuid_7_0_ecx_feature_name error.
> 
> Changes in v2:
> *Fix memcpy error for xsave state.
> *Fix TCG_7_0_ECX_FEATURES to 0.
> *Make subjects more readable.
> 
> The protection-key feature provides an additional mechanism by which IA-32e
> paging controls access to usermode addresses.
> 
> Hardware support for protection keys for user pages is enumerated with CPUID
> feature flag CPUID.7.0.ECX[3]:PKU. Software support is CPUID.7.0.ECX[4]:OSPKE
> with the setting of CR4.PKE(bit 22).
> 
> The PKRU register is XSAVE-managed state CPUID.D.0.EAX[9], the size of XSAVE
> state component for PKRU is 8 bytes, the offset is 0xa80.

Is every CPU supporting PKU guaranteed to have
CPUID.(EAX=0DH,ECX=9):EBX = 0xa80? Where is the PKRU state
offset/layout documented?

> 
> The specification of Protection Keys can be found at SDM (4.6.2, volume 3)
> http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf.
> 
[...]

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Qemu-devel] [PATCH v3 0/3] target-i386: add memory protection-key support

2015-11-18 Thread Paolo Bonzini


On 18/11/2015 18:51, Eduardo Habkost wrote:
> Is every CPU supporting PKU guaranteed to have
> CPUID.(EAX=0DH,ECX=9):EBX = 0xa80?

We asked Intel a while ago when reorganizing XSAVE support in KVM and
QEMU.  Unfortunately, Intel is not listing the offsets anymore in the
documentation, but they confirmed at the time that offsets won't change.

http://lists.xen.org/archives/html/xen-devel/2013-09/msg00484.html is
pretty clear in this respect:

>> [adding H. Peter Anvin... the context is whether the layout of the
>> XSAVE/XRSTOR area is fixed, including the offset of each separate
>> Ext_SAVE_Area].
> 
> It is.
> 
>> So please Intel, pretty please do not modify the XSAVE offsets, and
>> clarify this as soon as possible.
> 
> They will not change.
> 
> -hpa


This of course doesn't mean that the 0xa80 is correct; it only means
that if it is correct, it will always stay correct. :)

It makes sense that 0xa80 is correct, since ECX=8 is a supervisor state
(thus never saved by XSAVE/XSAVEOPT).

The fact that standard format does not account for supervisor states
means that supporting supervisor states in KVM might encounter a few
small complications.  In particular we might have to modify KVM and QEMU
to support compacted format in KVM_GET/SET_XSAVE.  For now the only
supervisor state is just a bunch of MSRs, so it would not be necessary
to include it in KVM_GET/SET_XSAVE.  Problem averted for now, then.

> Where is the PKRU state offset/layout documented?

Volume 1 of the SDM, section 13.5.7 ("PKRU State") documents the layout.
 (Careful: chapter 13 of volume 1 is "Managing State Using the XSAVE
Feature Set"; chapter 13 of volume 3 is "System Programming for
Instruction Set Extensions and Processor Extended States", and also
deals with XSAVE).

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html