On Fri, Dec 16, 2022 at 06:42:15PM +0000, Jonathan Cameron wrote:
> 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!
I do have updates to handle more than 3 records at a time which I was polishing
until I saw your review.
I was getting all geared up to respin the patches but I'm not sure there is an
issue now that I look at it.
I'm still investigating.
Ira
>
> 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,
>
