qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/7] PPC: Implement e500 (FSL) MMU


From: Scott Wood
Subject: Re: [Qemu-devel] [PATCH 5/7] PPC: Implement e500 (FSL) MMU
Date: Mon, 9 May 2011 14:42:57 -0500

On Mon, 9 May 2011 21:36:12 +0200
Alexander Graf <address@hidden> wrote:

> 
> On 09.05.2011, at 21:27, Scott Wood wrote:
> 
> > On Sat, 7 May 2011 23:36:29 +0200
> > Alexander Graf <address@hidden> wrote:
> > 
> >> On 07.05.2011, at 00:25, Scott Wood wrote:
> >>>> +void helper_booke206_tlbsx(target_ulong address_hi, target_ulong 
> >>>> address_lo)
> >>> 
> >>> What is address_hi?
> >>> 
> >>> From gen_tlbsx_booke206() it looks like these two arguments correspond to
> >>> the two operands, so shouldn't they be added together?  I only see
> >>> address_lo used.
> >> 
> >> Yup. According to the e500 spec:
> >> 
> >>  Note that rA = 0 is the preferred form for tlbsx and that some Freescale 
> >> implementations, such as the e500, take an illegal instruction exception 
> >> program interrupt if rA!=0.
> >> 
> >> So I figured that we're architecturally close enough if we just ignore it 
> >> for now :).
> > 
> > Architecturally, ignoring it and taking a trap are significantly
> > different. :-)
> > 
> > In practice it won't matter much, but it seems simple to handle it (why
> > handle it in tlbivax but not here?), especially if this is to be general
> > book3e code rather than e500.  I'm still confused about the "address_hi/lo"
> > naming.
> 
> So what would you prefer? Just do whatever the 2.06 spec says and ignore e500 
> specifics? :) Or always do what the e500 spec says?

Do what the architecture says.  I doubt any software is going to be worse
off if this instruction form succeeds rather than traps -- if such a
situation actually turns up, we can deal with it then.

-Scott




reply via email to

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