Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD Trinity systems

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, May 30, 2012 at 09:48:51AM -0500, Jacob Shin wrote:
> On Wed, May 30, 2012 at 04:02:48PM +0200, Andre Przywara wrote:
> > On 05/30/2012 03:33 PM, Jan Beulich wrote:
> > >>>>On 30.05.12 at 15:10, Andre Przywara<andre.przywara@amd.com>  wrote:
> > >>Because we are behind a family check before tweaking the topology
> > >>bit, we can use the standard rd/wrmsr variants for the CPUID feature
> > >>register.
> > >>This fixes a crash when using the kernel as a Xen Dom0 on affected
> > >>Trinity systems. The wrmsrl_amd_safe is not properly paravirtualized
> > >>yet (this will be fixed in another patch).
> > >
> > >I'm not following: If the AMD variants (putting a special value into
> > >%edi) can be freely replaced by the non-AMD variants, why did
> > >the AMD special ones get used in the first place?
> > 
> > Older CPUs (K8) needed the AMD variants, starting with family 10h we
> > can use the normal versions.
> > 
> > >Further, I can't see how checking_wrmsrl() is being paravirtualized
> > >any better than wrmsrl_amd_safe() - both have nothing but an
> > >exception handling fixup attached to the wrmsr invocation. Care
> > >to point out what actual crash it is that was seen?
> > 
> > AFAIK, the difference is between the "l" and the regs version for
> > rd/wrmsr. We have a patch already here to fix this. Will send it out
> > soon. Jacob, can you comment on this?
> 
> Right, the checking_wrmsrl turns into wrmsr_safe which is paravirtualized
> but the rdmsrl_amd_safe which turns into rdmsr_regs is not paravirtualized
> by enlighten.

So would a patch to implements the rdmsr_regs fix this crash?