Hi Eduardo,
Thanks for the feedback. All the suggestions make sense..
On Mon, Dec 14, 2015 at 02:23:56PM -0200, Eduardo Habkost wrote:
> > +static void feature_control_init(X86CPU *cpu)
> > +{
> > + CPUX86State *cenv = &cpu->env;
> > +
> > + cenv->msr_ia32_feature_control = ((1<<20) | (1<<0));
>
> FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_LMCE macros would make
> the code clearer.
Makes sense.. will fix it next round.
> > @@ -282,8 +282,9 @@
> >
> > #define MCG_CTL_P (1ULL<<8) /* MCG_CAP register available */
> > #define MCG_SER_P (1ULL<<24) /* MCA recovery/new status bits */
> > +#define MCG_LMCE_P (1ULL<<27) /* Local Machine Check Supported */
>
> Please use spaces instead of tabs. You can detect this and other
> coding style issues in this patch with checkpatch.pl.
>
Will change the ones i added.
>
> >
> > -#define MCE_CAP_DEF (MCG_CTL_P|MCG_SER_P)
> > +#define MCE_CAP_DEF (MCG_CTL_P|MCG_SER_P|MCG_LMCE_P)
>
> This makes mcg_cap change when upgrading QEMU.
>
> VMs with MCG_LMCE_P enabled shouldn't be migratable to hosts
> running older kernels, or the guest may try to read or write
> MSR_IA32_MCG_EXT_CTL after miration and get a #GP. That means:
>
> 1) Older machine-types (pc-2.5 and older) should keep the
> old (MCG_CTL_P|MCG_SER_P) default.
> 2) We can't make pc-2.6 enable LMCE by default, either, because
> QEMU guarantees that just changing the machine-type shouldn't
> introduce new host requirements (see:
> http://article.gmane.org/gmane.comp.emulators.qemu/346651)
>
> It looks like we need a new -cpu option to enable the feature,
> then. At least until we raise the minimum kernel version
> requirements of QEMU.
Ok.. i will look this up.
>
> (I didn't review the kvm_mce_inject() changes as I am not
> familiar with the details of how LMCE is implemented.)
>
This is quite simple.. we just don't broadcast MCE's and set LMCE in
MCG_STATUS.
I will make the suggested changes and resend.
Cheers,
Ashok
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
