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@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
