Re: [Xen-devel] [PATCH v2 08/12] x86/vmce: enable injecting LMCE to guest on Intel host

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.03.17 at 07:46, <haozhong.zhang@xxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel