From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <groug@kaod.org>
Cc: qemu-ppc@nongnu.org, "Cédric Le Goater" <clg@kaod.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 2/7] spapr, xive: Turn "nr-ends" property into "nr-servers" property
Date: Fri, 4 Oct 2019 14:07:25 +1000 [thread overview]
Message-ID: <20191004040725.GB27597@umbus.fritz.box> (raw)
In-Reply-To: <157010406203.246126.13381271918474281392.stgit@bahia.lan>
[-- Attachment #1: Type: text/plain, Size: 5568 bytes --]
On Thu, Oct 03, 2019 at 02:01:13PM +0200, Greg Kurz wrote:
> The sPAPR XIVE object has an nr_ends field which happens to be a
> multiple of spapr_max_server_number(). It is currently set with
> the help of "nr-ends" property. This is a bit unfortunate since
> it exposes to the sPAPR irq frontend what should remain an
> implemantation detail within the XIVE backend.
>
> It will be possible soon to inform the XIVE KVM device about the
> range of VCPU ids that may be used in the VM, as returned by the
> spapr_max_server_number() function. This will allow the device
> to substantially reduce the consumption of scarce resources
> in the XIVE HW.
>
> For both reasons, replace the "nr-ends" property with an "nr-servers"
> one. The existing nr_ends field must be kept though since it tells how
> many ENDs are migrated, it is derived from "nr-servers" at realize time
> for simplicity. Convert spapr_dt_xive() to use it as well.
>
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
> hw/intc/spapr_xive.c | 21 ++++++++++++++++-----
> hw/ppc/spapr_irq.c | 2 +-
> include/hw/ppc/spapr_xive.h | 1 +
> 3 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 04879abf2e7a..62888ddc68db 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -99,6 +99,15 @@ int spapr_xive_end_to_target(uint8_t end_blk, uint32_t end_idx,
> return 0;
> }
>
> +static uint32_t spapr_xive_vcpu_id_to_end_idx(uint32_t vcpu_id)
> +{
> + /*
> + * 8 XIVE END structures per CPU. One for each available
> + * priority
> + */
> + return vcpu_id << 3;
> +}
> +
> static void spapr_xive_cpu_to_end(PowerPCCPU *cpu, uint8_t prio,
> uint8_t *out_end_blk, uint32_t *out_end_idx)
> {
> @@ -109,7 +118,7 @@ static void spapr_xive_cpu_to_end(PowerPCCPU *cpu, uint8_t prio,
> }
>
> if (out_end_idx) {
> - *out_end_idx = (cpu->vcpu_id << 3) + prio;
> + *out_end_idx = spapr_xive_vcpu_id_to_end_idx(cpu->vcpu_id) + prio;
> }
> }
>
> @@ -283,11 +292,13 @@ static void spapr_xive_realize(DeviceState *dev, Error **errp)
> return;
> }
>
> - if (!xive->nr_ends) {
> - error_setg(errp, "Number of interrupt needs to be greater 0");
> + if (!xive->nr_servers) {
> + error_setg(errp, "Number of interrupt servers must be greater than 0");
> return;
> }
>
> + xive->nr_ends = spapr_xive_vcpu_id_to_end_idx(xive->nr_servers);
I'd prefer not to store both nr_servers and nr_servers * 8 in the
structure. I think you just want xive->nr_servers, then derive it any
any places that current look at xive->nr_ends.
> /*
> * Initialize the internal sources, for IPIs and virtual devices.
> */
> @@ -489,7 +500,7 @@ static const VMStateDescription vmstate_spapr_xive = {
>
> static Property spapr_xive_properties[] = {
> DEFINE_PROP_UINT32("nr-irqs", SpaprXive, nr_irqs, 0),
> - DEFINE_PROP_UINT32("nr-ends", SpaprXive, nr_ends, 0),
> + DEFINE_PROP_UINT32("nr-servers", SpaprXive, nr_servers, 0),
Technically speaking the user can reach in using -global and modify
QOM properties like this, so this is arguably an interface breakage.
That said, I've always thought it was kind of a problem that the way
QOM is used internally thereby exposes as interface a bunch of things
that are really intended to be internal.
So... I'm inclined to go ahead with this anyway. I won't tell if you
don't.
> DEFINE_PROP_UINT64("vc-base", SpaprXive, vc_base, SPAPR_XIVE_VC_BASE),
> DEFINE_PROP_UINT64("tm-base", SpaprXive, tm_base, SPAPR_XIVE_TM_BASE),
> DEFINE_PROP_END_OF_LIST(),
> @@ -1550,7 +1561,7 @@ void spapr_dt_xive(SpaprMachineState *spapr, uint32_t nr_servers, void *fdt,
> /* Interrupt number ranges for the IPIs */
> uint32_t lisn_ranges[] = {
> cpu_to_be32(0),
> - cpu_to_be32(nr_servers),
> + cpu_to_be32(xive->nr_servers),
> };
> /*
> * EQ size - the sizes of pages supported by the system 4K, 64K,
> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> index 457eabe24cda..025fd00143a2 100644
> --- a/hw/ppc/spapr_irq.c
> +++ b/hw/ppc/spapr_irq.c
> @@ -591,7 +591,7 @@ void spapr_irq_init(SpaprMachineState *spapr, Error **errp)
> * 8 XIVE END structures per CPU. One for each available
> * priority
> */
> - qdev_prop_set_uint32(dev, "nr-ends", nr_servers << 3);
> + qdev_prop_set_uint32(dev, "nr-servers", nr_servers);
> qdev_init_nofail(dev);
>
> spapr->xive = SPAPR_XIVE(dev);
> diff --git a/include/hw/ppc/spapr_xive.h b/include/hw/ppc/spapr_xive.h
> index 0df20a6590a5..4a4a6fc6be7f 100644
> --- a/include/hw/ppc/spapr_xive.h
> +++ b/include/hw/ppc/spapr_xive.h
> @@ -22,6 +22,7 @@ typedef struct SpaprXive {
> /* Internal interrupt source for IPIs and virtual devices */
> XiveSource source;
> hwaddr vc_base;
> + uint32_t nr_servers;
This is a basic paraneter, not really related to the internal source
structure, so I'd move it up above that comment there.
>
> /* END ESB MMIOs */
> XiveENDSource end_source;
>
--
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-10-04 4:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 12:00 [PATCH 0/7] spapr: Use less XIVE HW resources in KVM Greg Kurz
2019-10-03 12:00 ` [PATCH 1/7] spapr, xics: Get number of servers with a XICSFabricClass method Greg Kurz
2019-10-03 12:24 ` Cédric Le Goater
2019-10-03 12:49 ` Greg Kurz
2019-10-03 12:58 ` Cédric Le Goater
2019-10-03 13:02 ` Greg Kurz
2019-10-03 13:19 ` Cédric Le Goater
2019-10-03 13:41 ` Greg Kurz
2019-10-03 13:59 ` Cédric Le Goater
2019-10-03 14:58 ` Greg Kurz
2019-10-03 12:01 ` [PATCH 2/7] spapr, xive: Turn "nr-ends" property into "nr-servers" property Greg Kurz
2019-10-03 12:21 ` Cédric Le Goater
2019-10-03 12:44 ` Greg Kurz
2019-10-04 4:07 ` David Gibson [this message]
2019-10-04 5:53 ` Cédric Le Goater
2019-10-04 6:52 ` Greg Kurz
2019-10-04 7:27 ` Cédric Le Goater
2019-10-04 6:51 ` Greg Kurz
2019-10-05 10:23 ` David Gibson
2019-10-03 12:01 ` [PATCH 3/7] spapr, xics, xive: Drop nr_servers argument in DT-related functions Greg Kurz
2019-10-03 12:25 ` Cédric Le Goater
2019-10-03 12:52 ` Greg Kurz
2019-10-03 12:01 ` [PATCH RFC 4/7] linux-headers: Update against 5.3-rc2 Greg Kurz
2019-10-03 12:01 ` [PATCH 5/7] spapr/xics: Configure number of servers in KVM Greg Kurz
2019-10-03 12:29 ` Cédric Le Goater
2019-10-03 12:55 ` Greg Kurz
2019-10-03 12:01 ` [PATCH 6/7] spapr/xive: " Greg Kurz
2019-10-03 12:30 ` Cédric Le Goater
2019-10-03 12:02 ` [PATCH 7/7] spapr: Set VSMT to smp_threads by default Greg Kurz
2019-10-14 6:12 ` David Gibson
2019-10-14 11:31 ` 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=20191004040725.GB27597@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=clg@kaod.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).