qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH qemu v15 15/17] spapr_pci: Get rid of dma_loibn


From: David Gibson
Subject: Re: [Qemu-ppc] [PATCH qemu v15 15/17] spapr_pci: Get rid of dma_loibn
Date: Fri, 8 Apr 2016 11:34:43 +1000
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Apr 07, 2016 at 05:10:53PM +1000, Alexey Kardashevskiy wrote:
> On 04/07/2016 10:50 AM, David Gibson wrote:
> >s/dma_loibn/dma_liobn/ in subject line.
> >
> >On Mon, Apr 04, 2016 at 07:33:44PM +1000, Alexey Kardashevskiy wrote:
> >>We are going to have 2 DMA windows which LIOBNs are calculated from
> >>the PHB index and the window number using the SPAPR_PCI_LIOBN macro
> >>so there is no actual use for dma_liobn.
> >>
> >>This replaces dma_liobn with SPAPR_PCI_LIOBN. This marks it as unused
> >>in the migration stream. This renames dma_liobn to _dma_liobn as we have
> >>to keep the property for the CLI compatibility and we need a storage
> >>for it, although it has never really been used.
> >>
> >>Signed-off-by: Alexey Kardashevskiy <address@hidden>
> >
> >This doesn't quite make sense.  We can't really do that without
> >entirely removing support for PHBs without an 'index' value.
> >Basically the idea of the PHB config parameters what that you either
> >specified just "index" or you specified *all* the relevant addresses.
> >Removing option 2 might be a reasonable idea, but it shouldn't just be
> >done as a side effect of this other change.  With this patch the
> >"specify everything" approach still has code, but can't work, because
> >such a device will never get a reasonable liobn (or worse, it might
> >get a duplicate liobn, because the index isn't verified in this mode).
> >
> >Then again.. the "index" approach has also bitten us with the problem
> >of the not-quite-big-enough MMIO space per-PHB,
> 
> Any new ideas on that front?

No, not really :(.

> I also keep in mind that we rather want to
> assign interrupt numbers pool to a PHB based on its index rather than
> allocate them from the global machine interrupt number space so this is one
> more vote for keeping the index.

True, if we removed the index option we'd have to have the irqs set
from a property as well, I think, which would just increase the pain.

> >so I'm not entirely
> >sure that making it the only choice is the right way to go either.
> 
> I can imagine the user wanting to change MMIO addresses (so they should
> remain properties) but changing LIOBN from the command line does not seem
> useful at all.

Sure, but that doesn't alter the fact that we shouldn't break the
no-index option without completely removing the no-index option.

> >The short term approach to handle DDW might be to instead add a
> >dma64_liobn property.
> 
> So everywhere where I want to have a loop through all TCE tables and use
> SPAPR_PCI_LIOBN(index, i), I cannot really do that if I have 2 separate
> properties. Not extremely convenient.

Hmm.. you could work around that.  Inside the structure you could have
a liobns[2] array which you step through, then the properties just set
the individual elements of the array.

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