[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 08/10] ppc/xive: Extend XiveTCTX with an router
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH 08/10] ppc/xive: Extend XiveTCTX with an router object pointer |
Date: |
Wed, 17 Jul 2019 12:08:09 +1000 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
On Mon, Jul 15, 2019 at 05:45:38PM +0200, Cédric Le Goater wrote:
> On 12/07/2019 03:15, David Gibson wrote:
> > On Wed, Jul 03, 2019 at 07:54:57AM +0200, Cédric Le Goater wrote:
> >> On 03/07/2019 04:07, David Gibson wrote:
> >>> On Sun, Jun 30, 2019 at 10:45:59PM +0200, Cédric Le Goater wrote:
> >>>> This is to perform lookups in the NVT table when a vCPU is dispatched
> >>>> and possibly resend interrupts.
> >>>
> >>> I'm slightly confused by this one. Aren't there multiple router
> >>> objects, each of which can deliver to any thread? In which case what
> >>> router object is associated with a specific TCTX?
> >>
> >> when a vCPU is dispatched on a HW thread, the hypervisor does a store
> >> on the CAM line to store the VP id. At that time, it checks the IPB in
> >> the associated NVT structure and notifies the thread if an interrupt is
> >> pending.
> >>
> >> We need to do a NVT lookup, just like the presenter in HW, hence the
> >> router pointer. You should look at the following patch which clarifies
> >> the resend sequence.
> >
> > Hm, ok.
> >
> >>>> Future XIVE chip will use a different class for the model of the
> >>>> interrupt controller. So use an 'Object *' instead of a 'XiveRouter *'.
> >>>
> >>> This seems odd to me, shouldn't it be an interface pointer or
> >>> something in that case?
> >>
> >> I have duplicated most of the XIVE models for P10 because the internal
> >> structures have changed. I managed to keep the XiveSource and XiveTCTX
> >> but we now have a Xive10Router, this is the reason why.
> >
> > Right, but XiveRouter and Xive10Router must have something in common
> > if they can both be used here. Usually that's expressed as a shared
> > QOM interface - in which case you can use a pointer to the interface,
> > rathe than using Object * which kind of implies *anything* can go
> > here.
>
> Yeah. I also think it would be better to have a common base object but
> the class don't have much in common. Here is what I have for now :
Uh.. QOM interfaces don't require there to be a common base object,
only common methods.
>
> P9:
>
> typedef struct XiveRouterClass {
> SysBusDeviceClass parent;
>
> /* XIVE table accessors */
> int (*get_eas)(XiveRouter *xrtr, uint8_t eas_blk, uint32_t eas_idx,
> XiveEAS *eas);
> int (*get_end)(XiveRouter *xrtr, uint8_t end_blk, uint32_t end_idx,
> XiveEND *end);
> int (*write_end)(XiveRouter *xrtr, uint8_t end_blk, uint32_t end_idx,
> XiveEND *end, uint8_t word_number);
> int (*get_nvt)(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
> XiveNVT *nvt);
> int (*write_nvt)(XiveRouter *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
> XiveNVT *nvt, uint8_t word_number);
> XiveTCTX *(*get_tctx)(XiveRouter *xrtr, CPUState *cs);
> uint8_t (*get_block_id)(XiveRouter *xrtr);
> } XiveRouterClass;
>
> and P10:
>
> typedef struct Xive10RouterClass {
> SysBusDeviceClass parent;
>
> /* XIVE table accessors */
> int (*get_eas)(Xive10Router *xrtr, uint8_t eas_blk, uint32_t eas_idx,
> Xive10EAS *eas);
> int (*get_end)(Xive10Router *xrtr, uint8_t end_blk, uint32_t end_idx,
> Xive10END *end);
> int (*write_end)(Xive10Router *xrtr, uint8_t end_blk, uint32_t end_idx,
> Xive10END *end, uint8_t word_number);
> int (*get_nvp)(Xive10Router *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
> Xive10NVP *nvt);
> int (*write_nvp)(Xive10Router *xrtr, uint8_t nvt_blk, uint32_t nvt_idx,
> Xive10NVP *nvt, uint8_t word_number);
> XiveTCTX *(*get_tctx)(Xive10Router *xrtr, CPUState *cs);
> uint8_t (*get_block_id)(XiveRouter *xrtr);
> uint32_t (*get_config)(Xive10Router *xrtr);
> } Xive10RouterClass;
>
> Only get_tctx() is common.
>
> The XIVE structures (END, NV*) used by the routing algo have changed a lot.
> Even the presenter has changed, because all the CAM lines have a slightly
> different format.
>
> C.
>
>
--
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
signature.asc
Description: PGP signature