[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221217164023.00007597@Huawei.com>
Date: Sat, 17 Dec 2022 16:40:23 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ira Weiny <ira.weiny@...el.com>
CC: Dan Williams <dan.j.williams@...el.com>,
Davidlohr Bueso <dave@...olabs.net>,
Bjorn Helgaas <helgaas@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Dave Jiang <dave.jiang@...el.com>,
<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
<linux-acpi@...r.kernel.org>, <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH V4 3/9] cxl/mem: Wire up event interrupts
On Fri, 16 Dec 2022 13:28:36 -0800
Ira Weiny <ira.weiny@...el.com> wrote:
> 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@...wei.com> wrote:
> >
> > > On Sun, 11 Dec 2022 23:06:21 -0800
> > > ira.weiny@...el.com wrote:
> > >
> > > > From: Davidlohr Bueso <dave@...olabs.net>
> > > >
> > > > 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@...nel.org>
> > > > Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > > > Co-developed-by: Ira Weiny <ira.weiny@...el.com>
> > > > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> > > > Signed-off-by: Davidlohr Bueso <dave@...olabs.net>
> > > >
> > >
> > > > +/**
> > > > + * 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.
Great. I'll work on other stuff in the meantime and hopefully we can get all the
error emulation upstream this QEMU cycle.
>
> 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,
> >
Powered by blists - more mailing lists