|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch 2/6] Xen/MCE: remove mcg_ctl and other adjustment for future vMCE
Jan Beulich wrote:
>>>> On 23.07.12 at 11:39, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> @@ -175,11 +179,16 @@
>> *val);
>> break;
>> case MSR_IA32_MCG_CTL:
>> - /* Always 0 if no CTL support */
>> if ( cur->arch.mcg_cap & MCG_CTL_P )
>> - *val = vmce->mcg_ctl & h_mcg_ctl;
>> - mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n",
>> - *val);
>> + {
>> + *val = ~0UL;
>> + mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL
>> 0x%"PRIx64"\n", *val); + } + else
>> + {
>> + mce_printk(MCE_QUIET, "MCE: no MCG_CTL\n");
>> + ret = -1;
>
> Is there a particular reason to make this access fault here, when
> it didn't before? I.e. was there anything wrong with the previous
> approach of returning zero on reads and ignoring writes when
> !MCG_CTL_P?
>
Semantically this code is better than previous approach, since !MCG_CTL_P means
unimplemented MCG_CTL so access it would generate GP#.
Thanks,
Jinsong
>> + }
>> break;
>> default:
>> ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr,
>> val) : 0; @@ -287,15 +296,16 @@ struct domain_mca_msrs *vmce =
>> dom_vmce(cur->domain); int ret = 1;
>>
>> - if ( !g_mcg_cap )
>> - return 0;
>> -
>> spin_lock(&vmce->lock);
>>
>> switch ( msr )
>> {
>> case MSR_IA32_MCG_CTL:
>> - vmce->mcg_ctl = val;
>> + if ( !(cur->arch.mcg_cap & MCG_CTL_P) )
>> + {
>> + mce_printk(MCE_QUIET, "MCE: no MCG_CTL\n"); +
>> ret = -1; + }
>> break;
>> case MSR_IA32_MCG_STATUS:
>> vmce->mcg_status = val;
>
> Other than that, the patch looks fine to me.
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |