From: Greg Kurz <groug@kaod.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: Daniel Henrique Barboza <danielhb@linux.ibm.com>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2 for-5.2 3/5] ppc/xive: Introduce dedicated kvm_irqchip_in_kernel() wrappers
Date: Fri, 7 Aug 2020 11:29:12 +0200 [thread overview]
Message-ID: <20200807112912.5ba553a2@bahia.lan> (raw)
In-Reply-To: <20200807091554.633833c5@bahia.lan>
On Fri, 7 Aug 2020 09:15:54 +0200
Greg Kurz <groug@kaod.org> wrote:
> On Thu, 6 Aug 2020 19:55:29 +0200
> Cédric Le Goater <clg@kaod.org> wrote:
>
[...]
> > > diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> > > index 705cf48176fc..aa46e3fcf512 100644
> > > --- a/include/hw/ppc/xive.h
> > > +++ b/include/hw/ppc/xive.h
> > > @@ -161,6 +161,7 @@ typedef struct XiveNotifier XiveNotifier;
> > > typedef struct XiveNotifierClass {
> > > InterfaceClass parent;
> > > void (*notify)(XiveNotifier *xn, uint32_t lisn);
> > > + bool (*in_kernel)(const XiveNotifier *xn);
> > > } XiveNotifierClass;
> > >
> > > /*
> > > @@ -396,6 +397,7 @@ typedef struct XivePresenterClass {
> > > uint8_t nvt_blk, uint32_t nvt_idx,
> > > bool cam_ignore, uint8_t priority,
> > > uint32_t logic_serv, XiveTCTXMatch *match);
> > > + bool (*in_kernel)(const XivePresenter *xptr);
> > > } XivePresenterClass;
> > >
> > > int xive_presenter_tctx_match(XivePresenter *xptr, XiveTCTX *tctx,
> > >
> > >
> >
> > It seems redundant. Can we introduce a new XiveBackend QOM interface
> > which would implement an in_kernel() handler ? and XiveRouter would
> > inherit from it.
> >
>
> Not sure to see how it would help... the XiveRouter type isn't used
> at the locations where we call kvm_irqchip_in_kernel(). Only
> XivePresenter and XiveNotifier...
>
Looking again at xive_source_realize(), I now realize (forgive the pun ;) that
the negative check on kvm_irqchip_in_kernel() is a bit awkward. We usually
do more stuff when we have a KVM backend, not less. The intent seems to be
that the ESB MMIO should point to either I/O sub-region when XIVE is emulated
or to a mmapped subregion when XIVE is backed by a KVM device. This can be
achieved with a container and overlapping sub-regions (prio 0 for emulated,
prio 1 for KVM). And we no longer need to hijack XiveNotifier.
So in the end, we only need the method for XivePresenter.
I'll cook a v3.
> > C.
> >
> >
> >
> >
> >
>
next prev parent reply other threads:[~2020-08-07 9:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 16:55 [PATCH v2 for-5.2 0/5] papr: Cleanups for XIVE and PHB Greg Kurz
2020-08-06 16:56 ` [PATCH v2 for-5.2 1/5] spapr/xive: Fix xive->fd if kvm_create_device() fails Greg Kurz
2020-08-06 16:56 ` [PATCH v2 for-5.2 2/5] spapr/xive: Simplify kvmppc_xive_disconnect() Greg Kurz
2020-08-06 16:56 ` [PATCH v2 for-5.2 3/5] ppc/xive: Introduce dedicated kvm_irqchip_in_kernel() wrappers Greg Kurz
2020-08-06 17:55 ` Cédric Le Goater
2020-08-07 7:15 ` Greg Kurz
2020-08-07 9:29 ` Greg Kurz [this message]
2020-08-06 16:56 ` [PATCH v2 for-5.2 4/5] spapr/xive: Convert KVM device fd checks to assert() Greg Kurz
2020-08-06 16:56 ` [PATCH v2 for-5.2 5/5] spapr: Simplify error handling in spapr_phb_realize() 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=20200807112912.5ba553a2@bahia.lan \
--to=groug@kaod.org \
--cc=clg@kaod.org \
--cc=danielhb@linux.ibm.com \
--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 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).