Re: [PATCH 2/3] x86/HVM: support (emulate) UMIP

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 07/12/16 15:39, Jan Beulich wrote:
>>>> On 07.12.16 at 16:31, <boris.ostrovsky@oracle.com> wrote:
>> On 12/07/2016 10:14 AM, Jan Beulich wrote:
>>>>>> On 07.12.16 at 16:10, <boris.ostrovsky@oracle.com> wrote:
>>>> On 12/07/2016 06:29 AM, Jan Beulich wrote:
>>>>>>>> On 06.12.16 at 17:23, <boris.ostrovsky@oracle.com> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel