[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |