On Fri, 7 Aug 2020 09:15:54 +0200
Greg Kurz <gr...@kaod.org> wrote:
> On Thu, 6 Aug 2020 19:55:29 +0200
> Cédric Le Goater <c...@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.
> >
> >
> >
> >
> >
>
