[PATCH V4] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx

Scott Wood scottwood at freescale.com
Sat Mar 9 11:49:13 EST 2013


On 03/08/2013 02:01:46 AM, Jia Hongtao-B38951 wrote:
> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, March 08, 2013 12:38 AM
> > To: Jia Hongtao-B38951
> > Cc: David Laight; Wood Scott-B07421; linuxppc-dev at lists.ozlabs.org;
> > Stuart Yoder
> > Subject: Re: [PATCH V4] powerpc/85xx: Add machine check handler to  
> fix
> > PCIe erratum on mpc85xx
> >
> > On 03/07/2013 02:06:05 AM, Jia Hongtao-B38951 wrote:
> > > Here is the ideas from Scott:
> > > "
> > > > +	if (is_in_pci_mem_space(addr)) {
> > > > +		inst = *(unsigned int *)regs->nip;
> > >
> > > Be careful about taking a fault here.  A simple TLB miss should be
> > > safe given that we shouldn't be accessing PCIe in the middle of
> > > exception code, but what if the mapping has gone away (e.g. a
> > > userspace driver had its code munmap()ed or swapped out)?  What if
> > > permissions allow execute but not read (not sure if Linux will  
> allow
> > > this, but the hardware does)?
> > >
> > > What if it happened in a KVM guest?  You can't access guest  
> addresses
> > > directly.
> > > "
> >
> > That means you need to be careful about how you read the  
> instruction, not
> > that you shouldn't do it at all.
> >
> > -Scott
> 
> I agree.
> 
> Do you have a more secure way to get the instruction?
> Or what should be done to avoid permission break issue?

probe_kernel_address() should take care of userspace issues.  As for  
KVM, if you see MSR_GS set, bail out and don't apply the workaround.   
Let KVM/QEMU deal with it as it wishes (e.g. reflect to the guest and  
let its machine check handler do the skipping).  On PR-mode KVM (e.g.  
on e500v2-based chips) there is no MSR_GS and it just looks like  
userspace code -- for now just pretend it is user mode.

-Scott


More information about the Linuxppc-dev mailing list