qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] target/ppc: Add E500 L2CSR0 write helper


From: Bin Meng
Subject: Re: [PATCH] target/ppc: Add E500 L2CSR0 write helper
Date: Wed, 10 Feb 2021 10:12:32 +0800

Hi David,

On Wed, Feb 10, 2021 at 10:09 AM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Wed, Feb 10, 2021 at 09:53:53AM +0800, Bin Meng wrote:
> > Hi David,
> >
> > On Wed, Feb 10, 2021 at 9:50 AM David Gibson
> > <david@gibson.dropbear.id.au> wrote:
> > >
> > > On Mon, Feb 08, 2021 at 05:40:58PM +0800, Bin Meng wrote:
> > > > From: Bin Meng <bin.meng@windriver.com>
> > > >
> > > > There are several bits in L2CSR0 (exists in the e500mc/e5500/e6500
> > > > core) that should be self-cleared when written:
> > > >
> > > > - L2FI  (L2 cache flash invalidate)
> > > > - L2FL  (L2 cache flush)
> > > > - L2LFC (L2 cache lock flash clear)
> > > >
> > > > Add a write helper to emulate this behavior.
> > > >
> > > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > >
> > > IIUC, these are essentially write-only bits - they have some side
> > > effect when written on real hardware, but won't ever be read back.  Is
> > > that correct?  Do you have a reference to hardware docs describing
> > > this behaviour?
> > >
> >
> > Please see https://www.nxp.com/files-static/32bit/doc/ref_manual/EREFRM.pdf,
> > chapter 3.11.2
>
> Ah, thanks.  So these actually don't operate quite how I was
> suggesting - they are readable, and return 1 until the operation is
> completed.
>
> So what you're effectively doing here is simulating the cache
> operations completing instantly - which is correct because we don't
> model the cache.
>
> Can you please clarify that in your commit message, including the
> pointer to the chip doc.

Sure, will do in v2.

>
> > > I'm assuming that because we don't model the L2 cache, it's ok that
> > > your implementation just ignores writing these bits, rather than
> > > performing the cache operations requested?
> >
> > Yes, guests may read back these bits to confirm the operation is done
> > by hardware after writing 1 to these bits.
> >
> > >
> > > Is that still true for the flash clear operation?
> >
> > Yes.
>
> Ah, yes, I see.  The name made me think this might be something like
> dcbz, which has visible effects on architected state.  This is just
> clearing cache locks, which we don't model in any case.
>

Thanks for the review.

Regards,
Bin



reply via email to

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