[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/3 V3] hvm, svm: Update AMD Thresholding MSR definitions



On Thu, Feb 06, 2014 at 10:57:18AM +0000, Jan Beulich wrote:
> >>> On 05.02.14 at 21:28, Aravind Gopalakrishnan 
> >>> <aravind.gopalakrishnan@xxxxxxx> wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1461,8 +1461,9 @@ static int svm_msr_read_intercept(unsigned int msr, 
> > uint64_t *msr_content)
> >          *msr_content = v->arch.hvm_svm.guest_sysenter_eip;
> >          break;
> >  
> > -    case MSR_IA32_MCx_MISC(4): /* Threshold register */
> > -    case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
> > +    case MSR_F10_MC4_MISC1: /* Threshold register */
> > +    case MSR_F10_MC4_MISC2:
> > +    case MSR_F10_MC4_MISC3:
> >          /*
> >           * MCA/MCE: We report that the threshold register is unavailable
> >           * for OS use (locked by the BIOS).
> > @@ -1660,8 +1661,9 @@ static int svm_msr_write_intercept(unsigned int msr, 
> > uint64_t msr_content)
> >          vpmu_do_wrmsr(msr, msr_content);
> >          break;
> >  
> > -    case MSR_IA32_MCx_MISC(4): /* Threshold register */
> > -    case MSR_F10_MC4_MISC1 ... MSR_F10_MC4_MISC3:
> > +    case MSR_F10_MC4_MISC1: /* Threshold register */
> > +    case MSR_F10_MC4_MISC2:
> > +    case MSR_F10_MC4_MISC3:
> >          /*
> >           * MCA/MCE: Threshold register is reported to be locked, so we 
> > ignore
> >           * all write accesses. This behaviour matches real HW, so guests 
> > should
> 
> While both of these changes are fine with the code as it currently
> is, they both rely on behavior that is sub-optimal and would hence
> need to be changed: Neither should MSR reads blindly read the
> hardware MSR as a fallback, nor should MSR write be blindly
> ignored. Yet with removing 0xC000040A from the explicit list of
> registers handled, a guest OS accessing this MSR (knowing it
> exists on Fam10) would start to see unexpected #GP faults as
> soon as the respective default cases would get corrected. And I
> assume you agree that correcting these default cases should not
> require the author to be particularly knowledgeable about AMD
> CPU family differences.
> 

So, just to be safe, it is better I don't touch this piece of
code here.. (you can ignore patch 1 of the series basically)

I'll condense the remaining changes into a single patch and
send it out separately.

Thanks
-Aravind.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.