On Mon, Aug 08, 2022 at 10:23:03AM +0800, Jinhao Fan wrote:
> at 12:35 PM, Jinhao Fan <fanjinhao...@ict.ac.cn> wrote:
>
> > static void nvme_irq_assert(NvmeCtrl *n, NvmeCQueue *cq)
> > {
> > if (cq->irq_enabled) {
> > if (msix_enabled(&(n->parent_obj))) {
> > + /* Initialize CQ irqfd */
> > + if (!cq->irqfd_enabled && n->params.ioeventfd && cq->cqid !=
> > 0) {
> > + int ret = nvme_init_cq_irqfd(cq);
> > + if (ret == 0) {
> > + cq->irqfd_enabled = true;
> > + }
> > + }
> > +
>
> Another question:
>
> In this version I left irqfd initialization to the first assertion of an
> irq. But I think it is better to initialize irqfd at cq creation time so we
> won’t bother checking it at each irq assertion. However if I put these code
> in nvme_init_cq(), irqfd does not work properly. After adding some
> tracepoints I found the MSI messages in MSI-X table changed after
> nvme_init_cq(). Specifically, the `data` field does not seem correct at the
> time when nvme_init_cq() is called.
>
> Keith, you must be familiar with how the nvme driver initializes CQs. Could
> you give some information on when I can safely use the contents in the MSI-X
> table?
The driver will create the cq with an allocated vector, but it's not activated
until after the driver wires it up to a handler. I think that's what you're
observing with the incomplete MSIx table entry on creation.
