qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge
Date: Tue, 24 Jul 2018 12:14:56 +1000
User-agent: Mutt/1.10.0 (2018-05-17)

On Tue, Jul 24, 2018 at 09:55:53AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote:
> > > 
> > > Now, this is an ICS subclass, so why shouldn't it directly poke at the
> > > target ICP ?
> > 
> > That's ok in theory, but causing it to expose the icp interface to a
> > new module isn't great.
> > 
> > > It's an alternate to the normal ICS since it behaves a bit
> > > differently (PQ bits & all).
> > 
> > AFAICT the PQ bits are effectively another filtering layer on top of
> > the same ICS logic as elsewhere.  I think it's better if we can share
> > that shared logic, rather than replicating it.
> 
> I don't know, is there much shared logic ? And the shared bits are the
> subclassing, that's handled that way...
> 
> This is really a different piece of HW, a separate ICS implementation,
> that has its own quirks, is configured via different registers, does
> EOI differently etc...
> 
> Even the resend stuff is done differently, the resend bitmap is
> actually SW visible via an IODA table.
> 
> I mean, we could (maybe we do these days not sure) have an ICS
> superclass wrapper on the actual icp_irq() but that's really all there
> is to it I think.

Hm, yeah, fair enough.  I realized what I was suggesting would
actually need another layer of qirqs than we have, so it's not a good
idea after all.  Ok, I'm happy proceeding with exposing icp_irq().

-- 
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]