On Fri, 16 Dec 2022 14:24:38 +0000
Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote:
> On Sun, 11 Dec 2022 23:06:21 -0800
> ira.weiny@xxxxxxxxx wrote:
>
> > From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
> >
> > Currently the only CXL features targeted for irq support require their
> > message numbers to be within the first 16 entries. The device may
> > however support less than 16 entries depending on the support it
> > provides.
> >
> > Attempt to allocate these 16 irq vectors. If the device supports less
> > then the PCI infrastructure will allocate that number. Upon successful
> > allocation, users can plug in their respective isr at any point
> > thereafter.
> >
> > CXL device events are signaled via interrupts. Each event log may have
> > a different interrupt message number. These message numbers are
> > reported in the Get Event Interrupt Policy mailbox command.
> >
> > Add interrupt support for event logs. Interrupts are allocated as
> > shared interrupts. Therefore, all or some event logs can share the same
> > message number.
> >
> > In addition all logs are queried on any interrupt in order of the most
> > to least severe based on the status register.
> >
> > Cc: Bjorn Helgaas <helgaas@xxxxxxxxxx>
> > Cc: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > Co-developed-by: Ira Weiny <ira.weiny@xxxxxxxxx>
> > Signed-off-by: Ira Weiny <ira.weiny@xxxxxxxxx>
> > Signed-off-by: Davidlohr Bueso <dave@xxxxxxxxxxxx>
> >
>
> > +/**
> > + * Event Interrupt Policy
> > + *
> > + * CXL rev 3.0 section 8.2.9.2.4; Table 8-52
> > + */
> > +enum cxl_event_int_mode {
> > + CXL_INT_NONE = 0x00,
> > + CXL_INT_MSI_MSIX = 0x01,
> > + CXL_INT_FW = 0x02
> > +};
> > +struct cxl_event_interrupt_policy {
> > + u8 info_settings;
> > + u8 warn_settings;
> > + u8 failure_settings;
> > + u8 fatal_settings;
>
> This is an issue for your QEMU code which has this set at 5 bytes.
> Guess our handling of record lengths needs updating now we have two different
> spec versions to support and hence these can have multiple lengths.
>
> Btw, do you have an updated version of the QEMU patches you can share?
Note that I'm happy to take your QEMU series forwards, just don't want to duplicate
stuff you have already done!
Jonathan
> I was planning on just doing the AER type RAS stuff for the first pull this cycle
> but given this set means we never reach that code I probably need to do QEMU
> support for this and the stuff to support those all in one go - otherwise
> no one will be able to test it :) We rather optimistically have the OSC set
> to say the OS can have control of these, but upstream code doesn't emulate
> anything yet. Oops. Should have pretended the hardware was handling them
> until we had this support in place in QEMU.
>
> Jonathan
>
> > +} __packed;
> > +
> > /**
> > * struct cxl_event_state - Event log driver state
> > *
> > @@ -288,6 +305,8 @@ enum cxl_opcode {
> > CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
> > CXL_MBOX_OP_GET_EVENT_RECORD = 0x0100,
> > CXL_MBOX_OP_CLEAR_EVENT_RECORD = 0x0101,
> > + CXL_MBOX_OP_GET_EVT_INT_POLICY = 0x0102,
> > + CXL_MBOX_OP_SET_EVT_INT_POLICY = 0x0103,
> > CXL_MBOX_OP_GET_FW_INFO = 0x0200,
> > CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
> > CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
