[Top][All Lists]
[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
- [Qemu-devel] [PATCH 2/7] PPC: Make MPC8544DS emulation work w/o KVM, (continued)