All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 3/3] spapr: introduce a fixed IRQ number space
Date: Mon, 18 Jun 2018 14:46:33 +0200	[thread overview]
Message-ID: <20180618144633.7dc1ba5f@bahia.lan> (raw)
In-Reply-To: <04de8df8-3951-442c-62f4-7ea0309c609b@kaod.org>

On Mon, 18 Jun 2018 13:31:26 +0200
Cédric Le Goater <clg@kaod.org> wrote:

> On 06/18/2018 11:54 AM, Greg Kurz wrote:
> > On Mon, 18 Jun 2018 10:56:55 +0200
> > Cédric Le Goater <clg@kaod.org> wrote:
> >   
> >> [ ... ]
> >>  
> >>>>> This is 4 irqs per PHB, hence up to 32 PHBs. Cool, we're currently
> >>>>> limited to 31 PHBs.
> >>>>>       
> >>>>>> +#define SPAPR_IRQ_MSI        0x1100  /* Offset of the dynamic range covered      
> >>>>>
> >>>>> We only support dynamic MSIs with PCI, maybe rename to SPAPR_IRQ_PCI_MSI ?      
> >>>>
> >>>> hmm, no. We could have CAPI devices there. remember ? ;)
> >>>>    
> >>>
> >>> Well... OpenCAPI devices are exposed to the OS as PCI devices, so I'm not
> >>> sure we need a CAPI specific range.    
> >>
> >> yes. so this range is common to all devices doing dynamic allocation
> >> of IRQs. How should we call it ? 
> >>  
> >>>>>> +                                      * by the bitmap allocator */      
> >>>>>
> >>>>> The range size is hence 1k (XICS_IRQS_SPAPR) for the time being.      
> >>>>
> >>>> in fact we could this bogus limit and use spapr->irq_map_nr now.
> >>>>    
> >>>
> >>> "we could *missing verb* this bogus limit"... so I'm not sure to
> >>> understand...    
> >>
> >> oups. We could use spapr->irq_map_nr instead of XICS_IRQS_SPAPR when
> >> defining : 
> >>
> >>     _FDT(fdt_setprop_cell(fdt, bus_off, "ibm,pe-total-#msi", XICS_IRQS_SPAPR));
> >>
> >> in spapr_pci.c
> >>  
> > 
> > Ah... yeah, I've always found weird that all PHBs advertise the same number
> > of available MSIs as the total number of irqs for the whole machine. And
> > putting spapr->irq_map_nr looks weird all the same if all PHBs rely on the
> > same bitmap actually.
> > 
> > I'm thinking of doing the other way around: keep XICS_IRQS_SPAPR in
> > "ibm,pe-total-#msi" and have one XICS_IRQS_SPAPR sized bitmap per PHB.  
> 
> That could be the place where to put the msi allocator.
> 

Are you suggesting to move @irq_map and @irq_map_nr to sPAPRPHBState and
to have these setup during PHB realize ? I guess we could do that.

> C.

  reply	other threads:[~2018-06-18 12:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 11:53 [Qemu-devel] [PATCH 0/3] introduce a fixed IRQ number space Cédric Le Goater
2018-06-15 11:53 ` [Qemu-devel] [PATCH 1/3] spapr: split the IRQ allocation sequence Cédric Le Goater
2018-06-15 13:14   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2018-06-15 17:21     ` Cédric Le Goater
2018-06-18  6:52       ` Greg Kurz
2018-06-18  4:00   ` [Qemu-devel] " David Gibson
2018-06-18 12:16     ` David Gibson
2018-06-18 16:15       ` Cédric Le Goater
2018-06-15 11:53 ` [Qemu-devel] [PATCH 2/3] spapr: remove unused spapr_irq routines Cédric Le Goater
2018-06-15 13:30   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2018-06-18  4:00   ` [Qemu-devel] " David Gibson
2018-06-15 11:53 ` [Qemu-devel] [PATCH 3/3] spapr: introduce a fixed IRQ number space Cédric Le Goater
2018-06-15 16:03   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2018-06-15 17:18     ` Cédric Le Goater
2018-06-18  8:42       ` Greg Kurz
2018-06-18  8:56         ` Cédric Le Goater
2018-06-18  9:54           ` Greg Kurz
2018-06-18 11:31             ` Cédric Le Goater
2018-06-18 12:46               ` Greg Kurz [this message]
2018-06-18 17:40                 ` Cédric Le Goater
2018-06-18 12:30     ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180618144633.7dc1ba5f@bahia.lan \
    --to=groug@kaod.org \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.