qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] ppc: Stop dumping state on all exceptions in li


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [PATCH] ppc: Stop dumping state on all exceptions in linux-user
Date: Wed, 03 Aug 2016 21:28:52 +1000

On Wed, 2016-08-03 at 12:05 +0100, Peter Maydell wrote:
> On 3 August 2016 at 09:02, Benjamin Herrenschmidt
> > <address@hidden> wrote:
> > 
> > Other archs don't do it, some programs catch signals just fine
> > and those dumps just clutter the output. Keep the dumps for cases
> > that aren't supposed to happen such as unknown codes.
> > 
> > > > Signed-off-by: Benjamin Herrenschmidt <address@hidden>
> > ---
> >  linux-user/main.c | 14 --------------
> >  1 file changed, 14 deletions(-)
> > 
> > diff --git a/linux-user/main.c b/linux-user/main.c
> > index eb9975c..8fbc5a6 100644
> > --- a/linux-user/main.c
> > +++ b/linux-user/main.c
> > @@ -1651,9 +1651,6 @@ void cpu_loop(CPUPPCState *env)
> >                        "Aborting\n");
> >              break;
> >          case POWERPC_EXCP_DSI:      /* Data storage exception              
> >   */
> > -            EXCP_DUMP(env, "Invalid data memory access: 0x" TARGET_FMT_lx 
> > "\n",
> > -                      env->spr[SPR_DAR]);
> > -            /* XXX: check this. Seems bugged */
> 
> Are you removing these XXX comments because you've checked the
> error code cases below? If so it would be useful to say so
> in the commit message...

Well I fix some of it in another patch...

To the best of my understanding we only ever generate
0x40000000 and 0x42000000 via ppc_cpu_handle_mmu_fault()
in user_only_helper.c unless there's another path to DSI
in user mode that I missed.

That being said, the comment isn't useful anyway. Nobody
looks at it :-)

I can respin with the comment back in or do put some blurb
in the cset comment, let me know.

BTW. I noticed, the generic path from the original signal
coming from the host kernel through to here loses the
information that would allow us to differenciate between
a map error (no mapping) or a protection fault.

It's a bit unfortunate, not sure if we can do much about it
though without stopping to hijack the existing MMU translate
hook in the CPU class and using a user mode dediated one that
takes that sort of info as an argument.

Cheers,
Ben.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]