[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP
On 12/7/16 23:06, Andrew Cooper wrote:
On 07/12/16 15:39, Jan Beulich wrote:
On 07.12.16 at 16:31, <boris.ostrovsky@xxxxxxxxxx> wrote:
On 12/07/2016 10:14 AM, Jan Beulich wrote:
On 07.12.16 at 16:10, <boris.ostrovsky@xxxxxxxxxx> wrote:
On 12/07/2016 06:29 AM, Jan Beulich wrote:
On 06.12.16 at 17:23, <boris.ostrovsky@xxxxxxxxxx> wrote:
On 12/06/2016 06:44 AM, Jan Beulich wrote:
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
__set_bit(X86_FEATURE_APIC, hvm_featureset);
/*
+ * Xen can often provide UMIP emulation to HVM guests even if the host
+ * doesn't have such functionality.
+ */
+ if ( cpu_has_vmx_dt_exiting || cpu_has_svm )
+ __set_bit(X86_FEATURE_UMIP, hvm_featureset);
I don't think I understand how this is going to work for processors that
don't support UMIP.
How, for example, can guest_cr[4] have X86_CR4_UMIP set on these
processors when CPUID will not show the feature being there?
What we allow the guest to see and what we store into hardware
registers are two different things: Note how svm_update_guest_cr()
masks off X86_CR4_UMIP from the vale to be put into the VMCB.
So that was kind of my question --- why would a guest ever try to set
this bit? As far as it is concerned, UMIP is not available and the guest
is then trying to set an unsupported bit in cr4. And that should result
in a #GP.
But the code fragment above adds the respective CPUID bit to the
permitted features. Believe me, I've tried this with a UMIP-enabled
Linux (including proper CPUID based detection).
Are you referring to these patches: https://lkml.org/lkml/2016/11/8/68 ?
If yes then they look to be Intel-specific.
No, I had written my own before these had been posted. I did
actually post mine too, but that was a week or so after theirs,
and theirs appears to be more complete.
If AMD decides to use CPUID0x7.ecx[2] for something else --- won't this
be a problem for this patch?
I think the two vendors meanwhile do a good job not interfering with
one another's CPUID bits. We'd have ugly problems elsewhere if any
new dual purpose CPUID bit appeared.
[root@minuet-1 ~]# head /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 96
[root@minuet-1 ~]# xen-cpuid
nr_features: 10
KEY 1d 1c e1d e1c Da1
7b0 7c0 e7d e8b 7d0
Static sets:
Known
b7ebfbff:fffef3ff:efd3fbff:2469bfff:0000000f:fdbfffff:0000001b:00000500:00000001:0000000c
Special
10000200:88200000:00000000:00000002:00000000:00002040:00000010:00000000:00000000:00000000
PV Mask
17c9cbf5:f6f83203:e2500800:042109e3:00000007:fdaf0b39:00000003:00000000:00000001:0000000c
HVM Shadow Mask
17cbfbff:f7f83223:ea500800:04218df7:0000000f:fdbf4bbb:00000003:00000000:00000001:0000000c
HVM Hap Mask
17cbfbff:f7fa3223:ee500800:04218df7:0000000f:fdbf4fbb:0000000b:00000000:00000001:0000000c
Dynamic sets:
Raw
178bfbff:fed8320b:2fd3fbff:2febbfff:00000001:000001a9:00000000:000037d9:00000000:00000000
Host
178bf3ff:f6d8320b:2fd3fbff:2469bfff:00000001:000001a9:00000000:00000500:00000000:00000000
PV
1789c3f5:f6f83203:23d1cbf5:042109e3:00000001:00000129:00000000:00000000:00000000:00000000
HVM
178bfbff:f6f83203:2fd3fbff:04218df7:00000001:000001a9:00000000:00000000:00000000:00000000
This processor already implements some of Intel's features from
0x7[0].ebx, including SMEP. According to marketing, AMD Zen processors
will add the ADX, RDSEED, SHA, CLFLUSHOPT and SMAP features
I can't reasonably see them using a different feature word.
~Andrew
I have checked on the family17h, the CPUID Fn0000_0007_ECX is reserved
same as other older models.
Suravee
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
