[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx] > Sent: Thursday, December 08, 2016 12:07 AM > > 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:000 > 00000:00000000 > PV Mask > 17c9cbf5:f6f83203:e2500800:042109e3:00000007:fdaf0b39:00000003:00000000:0000 > 0001:0000000c > HVM Shadow Mask > 17cbfbff:f7f83223:ea500800:04218df7:0000000f:fdbf4bbb:00000003:00000000:00000 > 001:0000000c > HVM Hap Mask > 17cbfbff:f7fa3223:ee500800:04218df7:0000000f:fdbf4fbb:0000000b:00000000:00000 > 001:0000000c > > Dynamic sets: > Raw > 178bfbff:fed8320b:2fd3fbff:2febbfff:00000001:000001a9:00000000:000037d9:000000 > 00:00000000 > Host > 178bf3ff:f6d8320b:2fd3fbff:2469bfff:00000001:000001a9:00000000:00000500:00000 > 000:00000000 > PV > 1789c3f5:f6f83203:23d1cbf5:042109e3:00000001:00000129:00000000:00000000:0000 > 0000:00000000 > HVM > 178bfbff:f6f83203:2fd3fbff:04218df7:00000001:000001a9:00000000:00000000:00000 > 000: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 There is agreement that common features will use the same fields. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |