All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: Greg Kurz <groug@kaod.org>
Cc: David Gibson <david@gibson.dropbear.id.au>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/3] spapr: introduce a new sPAPRIrq backend
Date: Mon, 10 Sep 2018 19:24:47 +0200	[thread overview]
Message-ID: <90b8c81e-bd7b-8516-7e27-69d77ba59b72@kaod.org> (raw)
In-Reply-To: <20180910170253.50f4cd88@bahia.lan>

On 09/10/2018 05:02 PM, Greg Kurz wrote:
> On Mon, 10 Sep 2018 13:02:19 +0200
> Cédric Le Goater <clg@kaod.org> wrote:
> 
>> Hello,
>>
>> This series adds a new sPAPRIrq backend increasing the number of
>> available IRQ numbers in pseries-3.1 machines. This change is an
>> opportunity to also fix the "ibm,pe-total-#msi" and remove the old
>> XICS_IRQS_SPAPR definition.
>>
> 
> This cleanup looks sane but I still have a concern with the semantics of
> "ibm,pe-total-#msi".
> 
> According to LoPAPR:
> 
> "ibm,pe-total-#msi"
> 
> property name defines the maximum number of Message Signaled Interrupts (MSI plus MSI-X) that are available
> to the PE below this device tree node. This number only indicates the number of available interrupts, not the num-
> ber assigned. The number assigned for an IOA may be obtained by Function 0 (Query only) of the ibm,change-msi
> RTAS call.
> prop-encoded-array: Maximum number of interrupts encoded as with encode-int.
> 
> IIUC, the PHB is given ibm,pe-total-#msi MSIs that it can assign to devices.
> 
> But we currently have only one global allocator in the machine, so having
> each PHB advertising the full range of the allocator still looks weird.

yes. Multiple PHBs share the same IRQ number space and in this
case the advertised number "ibm,pe-total-#msi" does not reflect 
the maximum number of allocatable interrupts per PHB.

The patch improves only the value for one PHB and, as of today, 
it is still wrong when Multiple PHBs are involved.

> Shouldn't this be divided by the number of PHBs ? Or should we have one
> separate allocator for each PHB ?

That would mean segmenting the IRQ number space and I am not 
fond of this solution because we have plenty of space to share:

	0xd00 MSIs

When we find a scenario reaching this limit, I think what we 
should do is to dynamically extend the IRQ number space in QEMU 
and in KVM. It should not be a problem.

We could also downsize "ibm,pe-total-#msi". It is quite big
today. some controllers do have a lot of IRQs but no more 
that a hundred. I might be wrong. 

C.

>> Thanks,
>>
>> C.
>>
>> Cédric Le Goater (3):
>>   spapr: introduce a spapr_irq class 'nr_msis' attribute
>>   spapr: increase the size of the IRQ number space
>>   spapr_pci: fix "ibm,pe-total-#msi" value
>>
>>  include/hw/ppc/spapr_irq.h |  2 ++
>>  include/hw/ppc/xics.h      |  2 --
>>  hw/ppc/spapr.c             |  1 +
>>  hw/ppc/spapr_irq.c         | 22 ++++++++++++++++++++--
>>  hw/ppc/spapr_pci.c         |  5 +++--
>>  5 files changed, 26 insertions(+), 6 deletions(-)
>>
> 

  reply	other threads:[~2018-09-10 17:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 11:02 [Qemu-devel] [PATCH 0/3] spapr: introduce a new sPAPRIrq backend Cédric Le Goater
2018-09-10 11:02 ` [Qemu-devel] [PATCH 1/3] spapr: introduce a spapr_irq class 'nr_msis' attribute Cédric Le Goater
2018-09-11  1:48   ` David Gibson
2018-09-11  4:41     ` Cédric Le Goater
2018-09-13  6:11       ` David Gibson
2018-09-10 11:02 ` [Qemu-devel] [PATCH 2/3] spapr: increase the size of the IRQ number space Cédric Le Goater
2018-09-11  1:49   ` David Gibson
2018-09-10 11:02 ` [Qemu-devel] [PATCH 3/3] spapr_pci: fix "ibm,pe-total-#msi" value Cédric Le Goater
2018-09-11  1:50   ` [Qemu-devel] [PATCH 3/3] spapr_pci: fix "ibm, pe-total-#msi" value David Gibson
2018-09-11  4:42     ` Cédric Le Goater
2018-09-10 15:02 ` [Qemu-devel] [PATCH 0/3] spapr: introduce a new sPAPRIrq backend Greg Kurz
2018-09-10 17:24   ` Cédric Le Goater [this message]
2018-09-11  1:52     ` David Gibson
2018-09-11  7:22       ` Greg Kurz

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=90b8c81e-bd7b-8516-7e27-69d77ba59b72@kaod.org \
    --to=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --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.