Re: [Xen-devel] [PATCH] x86, amd_ucode: Safeguard against #GP

[Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>]

On 5/23/2014 1:05 AM, Jan Beulich wrote:
> > > > On 22.05.14 at 17:59, <aravind.gopalakrishnan@xxxxxxx> wrote:
> > On 5/22/2014 3:44 AM, Jan Beulich wrote:
> > > > > > On 21.05.14 at 23:28, <aravind.gopalakrishnan@xxxxxxx> wrote:
> > > > When HW tries to load a corrupted patch, it generates #GP
> > > > and hangs the system. Use wrmsr_safe instead so that we
> > > > fail to load microcode gracefully.
> > > >
> > > > Example on a Fam15h system-
> > > > (XEN) microcode: CPU0 collect_cpu_info: patch_id=0x6000626
> > > > (XEN) microcode: CPU0 size 7870, block size 2586 offset 76 equivID
> > > > 0x6012 rev 0x6000637
> > > > (XEN) microcode: CPU0 found a matching microcode update with version
> > > > 0x6000637 (current=0x6000626)
> > > > (XEN) traps.c:3073: GPF (0000): ffff82d08016f682 -> ffff82d08022d9f8
> > > > (XEN) microcode: CPU0 update from revision 0x6000637 to 0x6000626 failed
> > > >
> > > > Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@xxxxxxx>
> > > > ---
> > > >    xen/arch/x86/microcode_amd.c |    2 +-
> > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
> > > > index e83f4b6..23637e2 100644
> > > > --- a/xen/arch/x86/microcode_amd.c
> > > > +++ b/xen/arch/x86/microcode_amd.c
> > > > @@ -191,7 +191,7 @@ static int apply_microcode(int cpu)
> > > >    
> > > >        spin_lock_irqsave(&microcode_update_lock, flags);
> > > >    
> > > > -    wrmsrl(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
> > > > +    wrmsr_safe(MSR_AMD_PATCHLOADER, (unsigned long)hdr);
> > > I think you shouldn't ignore the "return" value here.
> > Not sure I understand..
> > Do you mean you want to capture return value and bubble it up? maybe
> > print a debug message too?
> Yes.
>
> > Since we check if patch application succeeded using -
> > if ( rev != hdr->patch_id )
> > and return a error val here, would this not be sufficient?
> It might, but I'm of the opinion that errors should never be ignored
> _and_ be detected as early as possible.
Have addressed above issues and sending out V2 with Boris' Reviewed-by tag.

Thanks,
-Aravind.

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