qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target/ppc: add external PID support


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH] target/ppc: add external PID support
Date: Mon, 10 Sep 2018 14:33:04 +1000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Sep 03, 2018 at 09:25:43AM +0200, Roman Kapl wrote:
> 
> On 08/31/2018 05:35 AM, David Gibson wrote:
> > On Tue, Aug 14, 2018 at 06:59:54PM +0200, Roman Kapl wrote:
> > > External PID is a mechanism present on BookE 2.06 that enables 
> > > application to
> > > store/load data from different address spaces. There are special version 
> > > of some
> > > instructions, which operate on alternate address space, which is 
> > > described in
> > > the EPLC/EPSC regiser.
> > > 
> > > This implementation uses two additional MMU modes (mmu_idx) to provide the
> > > address space for the load and store instructions. The QEMU TLB fill code 
> > > was
> > > modified to recognize these MMU modes and use the values in EPLC/EPSC to 
> > > find
> > > the proper entry in he PPC TLB. These two QEMU TLBs are also flushed on 
> > > each
> > > write to EPLC/EPSC.
> > > 
> > > Following instructions are implemented: dcbfep dcbstep dcbtep dcbtstep 
> > > dcbzep
> > > dcbzlep icbiep lbepx ldepx lfdepx lhepx lwepx stbepx stdepx stfdepx sthepx
> > > stwepx.
> > > 
> > > Following vector instructions are not: evlddepx evstddepx lvepx lvepxl 
> > > stvepx
> > > stvepxl.
> > > 
> > > Signed-off-by: Roman Kapl <address@hidden>
> > 
> > Looks like a good first draft.  I have a few comments dispersed below.
> > 
> > On a more general level, I'm not totally clear on how the new mmu
> > indices work.  AIUI these essentially index different qemu TLBs (as
> > opposed to modelled hardware TLBs).  If the EP was set to the same PID
> > as the current process you'd have two indices essentially aliased to
> > each other - in that case do we have all the necessary flushes in
> > place?
> 
> That is a good point (i assume you mean QEMU TLB flush). The existing code
> seems to always call tlb_flush, not tlb_flush_mmuidx, so it should wipe out
> all QEMU TLBs, including the EPID ones, whenever the HW TLB changes. You
> could already have this aliasing even without EPID in the different TLB
> modes for supervisor/user etc. Can you think of any other reasons why the
> aliasing would be a problem?

Hm, no, I guess you're right.  I can't say I understand the mmuidx
stuff as well as I'd like, but I think your approach should work.

I'll await v2.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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