[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.