[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH] target/ppc: add external PID support
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [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
signature.asc
Description: PGP signature