qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-ppc@nongnu.org, Greg Kurz <groug@kaod.org>,
	Suraj Jitindar Singh <sjitindarsingh@gmail.com>,
	qemu-devel@nongnu.org
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	[thread overview]
Message-ID: <20190717020809.GE9123@umbus.fritz.box> (raw)
In-Reply-To: <4f2f24e7-28da-8f32-e1f7-721dc6533e7c@kaod.org>

[-- Attachment #1: Type: text/plain, Size: 4387 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-07-17  3:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-30 20:45 [Qemu-devel] [PATCH 00/10] ppc/pnv: add XIVE support for KVM guests Cédric Le Goater
2019-06-30 20:45 ` [Qemu-devel] [PATCH 01/10] ppc/xive: Force the Physical CAM line value to group mode Cédric Le Goater
2019-07-01  5:26   ` David Gibson
2019-06-30 20:45 ` [Qemu-devel] [PATCH 02/10] ppc/xive: Make the PIPR register readonly Cédric Le Goater
2019-07-01  5:27   ` David Gibson
2019-06-30 20:45 ` [Qemu-devel] [PATCH 03/10] ppc/pnv: Rework cache watch model of PnvXIVE Cédric Le Goater
2019-07-01  5:32   ` David Gibson
2019-06-30 20:45 ` [Qemu-devel] [PATCH 04/10] ppc/xive: Fix TM_PULL_POOL_CTX special operation Cédric Le Goater
2019-07-01  5:32   ` David Gibson
2019-06-30 20:45 ` [Qemu-devel] [PATCH 05/10] ppc/xive: Implement TM_PULL_OS_CTX special command Cédric Le Goater
2019-06-30 20:45 ` [Qemu-devel] [PATCH 06/10] ppc/xive: Provide escalation support Cédric Le Goater
2019-06-30 20:45 ` [Qemu-devel] [PATCH 07/10] ppc/xive: Improve 'info pic' support Cédric Le Goater
2019-06-30 20:45 ` [Qemu-devel] [PATCH 08/10] ppc/xive: Extend XiveTCTX with an router object pointer Cédric Le Goater
2019-07-03  2:07   ` David Gibson
2019-07-03  5:54     ` Cédric Le Goater
2019-07-12  1:15       ` David Gibson
2019-07-15 15:45         ` Cédric Le Goater
2019-07-17  2:08           ` David Gibson [this message]
2019-07-17  8:35             ` Cédric Le Goater
2019-06-30 20:46 ` [Qemu-devel] [PATCH 09/10] ppc/xive: Synthesize interrupt from the saved IPB in the NVT Cédric Le Goater
2019-06-30 20:46 ` [Qemu-devel] [PATCH 10/10] ppc/pnv: Dump the XIVE NVT table Cédric Le Goater
2019-07-03  2:10 ` [Qemu-devel] [PATCH 00/10] ppc/pnv: add XIVE support for KVM guests David Gibson
2019-07-03  5:56   ` Cédric Le Goater

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=20190717020809.GE9123@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 \
    --cc=sjitindarsingh@gmail.com \
    /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).