On 02/23/17 02:28 -0700, Jan Beulich wrote: > Storing -1 into both fields was misleading consumers: We really should > have a manifest constant for "invalid vCPU" here, and the already > existing DOMID_INVALID should be used. > > Also correct a bogus (dead code) check in mca_init_global(), at once > introducing a manifest constant for the early boot "invalid vCPU" > pointer (avoiding proliferation of the open coding). Make that pointer > a non-canonical address at once. > > Finally, don't leave mc_domid uninitialized in mca_init_bank(). > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > TBD: Do we need to change XEN_MCA_INTERFACE_VERSION due to the 0xffff > -> DOMID_INVALID change for what mc_domid defaults to? > > --- a/xen/arch/x86/cpu/mcheck/mcaction.c > +++ b/xen/arch/x86/cpu/mcheck/mcaction.c > @@ -100,7 +100,8 @@ mc_memerr_dhandler(struct mca_binfo *bin > goto vmce_failed; > } > > - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) > + if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL || > + global->mc_vcpuid == XEN_MC_VCPUID_INVALID) > vmce_vcpuid = VMCE_INJECT_BROADCAST; > else > vmce_vcpuid = global->mc_vcpuid;
If an invalid vcpuid is got on AMD machine, should we report error or inject to a default vcpu (vcpu0?) ? Haozhong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
