On Fri, Nov 16, 2018 at 11:56:57AM +0100, Cédric Le Goater wrote:
> The XiveRouter models the second sub-engine of the overall XIVE
> architecture : the Interrupt Virtualization Routing Engine (IVRE).
>
> The IVRE handles event notifications of the IVSE through MMIO stores
> and performs the interrupt routing process. For this purpose, it uses
> a set of table stored in system memory, the first of which being the
> Event Assignment Structure (EAS) table.
>
> The EAT associates an interrupt source number with an Event Notification
> Descriptor (END) which will be used in a second phase of the routing
> process to identify a Notification Virtual Target.
>
> The XiveRouter is an abstract class which needs to be inherited from
> to define a storage for the EAT, and other upcoming tables. The
> 'chip-id' atttribute is not strictly necessary for the sPAPR and
> PowerNV machines but it's a good way to test the routing algorithm.
> Without this atttribute, the XiveRouter could be a simple QOM
> interface.
>
> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> ---
> include/hw/ppc/xive.h | 32 ++++++++++++++
> include/hw/ppc/xive_regs.h | 31 ++++++++++++++
> hw/intc/xive.c | 86 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 149 insertions(+)
> create mode 100644 include/hw/ppc/xive_regs.h
>
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index be93fae6317b..5a0696366577 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -11,6 +11,7 @@
> #define PPC_XIVE_H
>
> #include "hw/sysbus.h"
> +#include "hw/ppc/xive_regs.h"
>
> /*
> * XIVE Fabric (Interface between Source and Router)
> @@ -168,4 +169,35 @@ static inline void xive_source_irq_set(XiveSource *xsrc,
> uint32_t srcno,
> }
> }
>
> +/*
> + * XIVE Router
> + */
> +
> +typedef struct XiveRouter {
> + SysBusDevice parent;
> +
> + uint32_t chip_id;
> +} XiveRouter;
> +
> +#define TYPE_XIVE_ROUTER "xive-router"
> +#define XIVE_ROUTER(obj) \
> + OBJECT_CHECK(XiveRouter, (obj), TYPE_XIVE_ROUTER)
> +#define XIVE_ROUTER_CLASS(klass) \
> + OBJECT_CLASS_CHECK(XiveRouterClass, (klass), TYPE_XIVE_ROUTER)
> +#define XIVE_ROUTER_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(XiveRouterClass, (obj), TYPE_XIVE_ROUTER)
> +
> +typedef struct XiveRouterClass {
> + SysBusDeviceClass parent;
> +
> + /* XIVE table accessors */
> + int (*get_eas)(XiveRouter *xrtr, uint32_t lisn, XiveEAS *eas);
> + int (*set_eas)(XiveRouter *xrtr, uint32_t lisn, XiveEAS *eas);
Sorry, didn't think of this in my first reply.
1) Does the hardware ever actually write back to the EAS? I know it
does for the END, but it's not clear why it would need to for the
EAS. If not, we don't need the setter.
2) The signatures are a bit odd here. For the setter, a value would
make sense than a (XiveEAS *), since it's just a word. For the getter
you could return the EAS value directly rather than using a pointer -
there's already a valid bit in the EAS so you can construct a value
with that cleared if the lisn is out of bounds.
--
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
