From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <groug@kaod.org>
Cc: "Alexey Kardashevskiy" <aik@ozlabs.ru>,
"Jason Wang" <jasowang@redhat.com>,
"Riku Voipio" <riku.voipio@iki.fi>,
qemu-devel@nongnu.org, "Laurent Vivier" <laurent@vivier.eu>,
"Alex Williamson" <alex.williamson@redhat.com>,
qemu-ppc@nongnu.org, clg@kaod.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
philmd@redhat.com
Subject: Re: [PATCH v4 19/19] spapr: Work around spurious warnings from vfio INTx initialization
Date: Wed, 9 Oct 2019 19:52:59 +1100 [thread overview]
Message-ID: <20191009085259.GA5035@umbus.fritz.box> (raw)
In-Reply-To: <20191009103738.01bc146a@bahia.lan>
[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]
On Wed, Oct 09, 2019 at 10:37:38AM +0200, Greg Kurz wrote:
> On Wed, 9 Oct 2019 17:08:18 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > Traditional PCI INTx for vfio devices can only perform well if using
> > an in-kernel irqchip. Therefore, vfio_intx_update() issues a warning
> > if an in kernel irqchip is not available.
>
> Can you elaborate on what doesn't "perform well" without an
> in-kernel irqchip ?
Not really, no, but Alex Williamson tells me it is soo.
> Is it a matter of performance or is it
> actually broken or something else ?
I believe it's a matter of performance, but such a big one that it
makes using it without kernel irqchip infeasible in many cases.
> What is the impact on -machine accel=kvm,kernel-irqchip=off which
> always spit this warning ?
It should still spit that warning.
> > We usually do have an in-kernel irqchip available for pseries machines
> > on POWER hosts. However, because the platform allows feature
> > negotiation of what interrupt controller model to use, we don't
> > currently initialize it until machine reset. vfio_intx_update() is
> > called (first) from vfio_realize() before that, so it can issue a
> > spurious warning, even if we will have an in kernel irqchip by the
> > time we need it.
> >
> > To workaround this, make a call to spapr_irq_update_active_intc() from
> > spapr_irq_init() which is called at machine realize time, before the
> > vfio realize. This call will be pretty much obsoleted by the later
> > call at reset time, but it serves to suppress the spurious warning
> > from VFIO.
> >
> > Cc: Alex Williamson <alex.williamson@redhat.com>
> > Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> > hw/ppc/spapr_irq.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> > index 7964e4a1b8..3aeb523f3e 100644
> > --- a/hw/ppc/spapr_irq.c
> > +++ b/hw/ppc/spapr_irq.c
> > @@ -274,6 +274,14 @@ void spapr_irq_init(SpaprMachineState *spapr, Error **errp)
> >
> > spapr->qirqs = qemu_allocate_irqs(spapr_set_irq, spapr,
> > smc->nr_xirqs + SPAPR_XIRQ_BASE);
> > +
> > + /*
> > + * Mostly we don't actually need this until reset, except that not
> > + * having this set up can cause VFIO devices to issue a
> > + * false-positive warning during realize(), because they don't yet
> > + * have an in-kernel irq chip.
> > + */
> > + spapr_irq_update_active_intc(spapr);
> > }
> >
> > int spapr_irq_claim(SpaprMachineState *spapr, int irq, bool lsi, Error **errp)
> > @@ -429,7 +437,8 @@ void spapr_irq_update_active_intc(SpaprMachineState *spapr)
> > * this.
> > */
> > new_intc = SPAPR_INTC(spapr->xive);
> > - } else if (spapr_ovec_test(spapr->ov5_cas, OV5_XIVE_EXPLOIT)) {
> > + } else if (spapr->ov5_cas
> > + && spapr_ovec_test(spapr->ov5_cas, OV5_XIVE_EXPLOIT)) {
> > new_intc = SPAPR_INTC(spapr->xive);
> > } else {
> > new_intc = SPAPR_INTC(spapr->ics);
>
--
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-09 16:59 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-09 6:07 [PATCH v4 00/19] spapr: IRQ subsystem cleanup David Gibson
2019-10-09 6:08 ` [PATCH v4 01/19] xive: Make some device types not user creatable David Gibson
2019-10-09 6:08 ` [PATCH v4 02/19] xics: " David Gibson
2019-10-09 6:08 ` [PATCH v4 03/19] target/ppc: Fix for optimized vsl/vsr instructions David Gibson
2019-10-09 6:08 ` [PATCH v4 04/19] spapr, xics, xive: Introduce SpaprInterruptController QOM interface David Gibson
2019-10-09 6:08 ` [PATCH v4 05/19] spapr, xics, xive: Move cpu_intc_create from SpaprIrq to SpaprInterruptController David Gibson
2019-10-09 6:08 ` [PATCH v4 06/19] spapr, xics, xive: Move irq claim and free " David Gibson
2019-10-09 6:08 ` [PATCH v4 07/19] spapr: Formalize notion of active interrupt controller David Gibson
2019-10-09 9:16 ` Cédric Le Goater
2019-10-09 9:19 ` Cédric Le Goater
2019-10-09 11:38 ` David Gibson
2019-10-09 6:08 ` [PATCH v4 08/19] spapr, xics, xive: Move set_irq from SpaprIrq to SpaprInterruptController David Gibson
2019-10-09 9:18 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 09/19] spapr, xics, xive: Move print_info " David Gibson
2019-10-09 9:19 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 10/19] spapr, xics, xive: Move dt_populate " David Gibson
2019-10-09 9:20 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 11/19] spapr, xics, xive: Match signatures for XICS and XIVE KVM connect routines David Gibson
2019-10-09 6:08 ` [PATCH v4 12/19] spapr: Remove SpaprIrq::init_kvm hook David Gibson
2019-10-09 6:08 ` [PATCH v4 13/19] spapr, xics, xive: Move SpaprIrq::reset hook logic into activate/deactivate David Gibson
2019-10-09 14:25 ` Greg Kurz
2019-10-09 15:56 ` Cédric Le Goater
2019-10-09 15:56 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 14/19] spapr, xics, xive: Move SpaprIrq::post_load hook to backends David Gibson
2019-10-09 15:57 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 15/19] spapr: Remove SpaprIrq::nr_msis David Gibson
2019-10-09 15:59 ` Cédric Le Goater
2019-10-10 1:56 ` David Gibson
2019-10-09 6:08 ` [PATCH v4 16/19] spapr: Move SpaprIrq::nr_xirqs to SpaprMachineClass David Gibson
2019-10-09 16:01 ` Cédric Le Goater
2019-10-09 6:08 ` [PATCH v4 17/19] spapr: Remove last pieces of SpaprIrq David Gibson
2019-10-09 16:44 ` Cédric Le Goater
2019-10-10 1:59 ` David Gibson
2019-10-09 17:02 ` Greg Kurz
2019-10-10 2:02 ` David Gibson
2019-10-10 6:29 ` Greg Kurz
2019-10-10 20:33 ` Greg Kurz
2019-10-11 5:07 ` David Gibson
2019-10-11 6:13 ` Greg Kurz
2019-10-11 8:33 ` Greg Kurz
2019-10-12 0:00 ` David Gibson
2019-10-14 9:15 ` Greg Kurz
2019-11-20 5:38 ` David Gibson
2019-11-20 8:36 ` Greg Kurz
2019-10-09 6:08 ` [PATCH v4 18/19] spapr: Handle irq backend changes with VFIO PCI devices David Gibson
2019-10-09 8:57 ` David Gibson
2019-10-09 6:08 ` [PATCH v4 19/19] spapr: Work around spurious warnings from vfio INTx initialization David Gibson
2019-10-09 8:37 ` Greg Kurz
2019-10-09 8:52 ` David Gibson [this message]
2019-10-09 17:16 ` Greg Kurz
2019-10-10 2:02 ` David Gibson
2019-10-09 9:02 ` [PATCH v4 00/19] spapr: IRQ subsystem cleanup David Gibson
2019-10-16 16:04 ` Greg Kurz
2019-10-17 0:26 ` 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=20191009085259.GA5035@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=clg@kaod.org \
--cc=groug@kaod.org \
--cc=jasowang@redhat.com \
--cc=laurent@vivier.eu \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=riku.voipio@iki.fi \
/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.