[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/altp2m: add altp2m_vcpu_disable_notify



On 12/18/18 4:10 PM, Jan Beulich wrote:
>>>> On 14.12.18 at 18:17, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
>> only possible to disable this functionality when we disable altp2m
>> completely; #VE/VMFUNC can only be enabled once per altp2m session.
>>
>> In addition to making things complete, disabling #VE is also a
>> workaround for CFW116 ("When Virtualization Exceptions are Enabled,
>> EPT Violations May Generate Erroneous Virtualization Exceptions")
>> on Xeon CPUs.
> 
> "Xeon CPUs" is overly generic. Yes, the CFW erratum prefix allows
> to identify which one you mean, but only (afaik) by going through
> the spec updates until you've found the right one. Can you please
> be more specific here?

Of course, sorry for the ambiguity. I was referring to the E-2100s:

https://www.intel.com/content/www/us/en/products/docs/processors/xeon/xeon-e-2100-specification-update.html

I will update the patch description.

>> @@ -4602,6 +4603,36 @@ static int do_altp2m_op(
>>          break;
>>      }
>>  
>> +    case HVMOP_altp2m_vcpu_disable_notify:
>> +    {
>> +        struct vcpu *v;
>> +
>> +        if ( a.u.disable_notify.pad ||
>> +             a.u.disable_notify.vcpu_id >= d->max_vcpus )
>> +        {
>> +            rc = -EINVAL;
>> +            break;
>> +        }
>> +
>> +        if ( !cpu_has_vmx_virt_exceptions )
>> +        {
>> +            rc = -EOPNOTSUPP;
>> +            break;
>> +        }
>> +
>> +        v = d->vcpu[a.u.enable_notify.vcpu_id];
>> +
>> +        if ( gfn_eq(vcpu_altp2m(v).veinfo_gfn, INVALID_GFN) )
>> +        {
>> +            rc = -EINVAL;
>> +            break;
>> +        }
> 
> Why? Disabling what is already disabled is not wrong, and hence
> could easily be treated as a no-op.

Just tought I'd actually report that this would be a no-op. But it's not
important, so I'll make it a no-op (simply break instead of setting rc
to -EINVAL).

>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -232,6 +232,13 @@ struct xen_hvm_altp2m_vcpu_enable_notify {
>>  typedef struct xen_hvm_altp2m_vcpu_enable_notify 
>> xen_hvm_altp2m_vcpu_enable_notify_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_vcpu_enable_notify_t);
>>  
>> +struct xen_hvm_altp2m_vcpu_disable_notify {
>> +    uint32_t vcpu_id;
>> +    uint32_t pad;
> 
> Why the pad field? There's no hole left.

Sorry, that was an oversight. I'll correct it.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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