>>> On 17.03.17 at 07:46, <haozhong.zh...@intel.com> wrote: > @@ -88,18 +89,31 @@ mc_memerr_dhandler(struct mca_binfo *binfo, > goto vmce_failed; > } > > - if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL || > - global->mc_vcpuid == XEN_MC_VCPUID_INVALID) > + mc_vcpuid = global->mc_vcpuid; > + if (mc_vcpuid == XEN_MC_VCPUID_INVALID || > + (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && > + (!(global->mc_gstatus & MCG_STATUS_LMCE) || > + !(d->vcpu[mc_vcpuid]->arch.vmce.lmce_enabled) || > + /* > + * The following check serves for MCE injection > + * test, i.e. xen-mceinj. xen-mceinj may specify > + * the target domain (i.e. bank->mc_domid) and > + * target CPU, but it's hard for xen-mceinj to > + * ensure, when Xen prepares the actual > + * injection in this function, vCPU currently > + * running on the target CPU belongs to the > + * target domain. If such inconsistency does > + * happen, fallback to broadcast. > + */ > + global->mc_domid != bank->mc_domid)))
Thinking about this another time, I don't think we want hackery like this for a test utility. Instead I think the test utility wants to pin the vCPU on the pCPU it wants to deliver the LMCE on. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
