search for: db_addr

...emory.h> #include <hw/block/block.h> #include <hw/hw.h> #include <hw/pci/msix.h> @@ -158,6 +159,14 @@ static uint16_t nvme_dma_read_prp(NvmeCtrl *n, uint8_t *ptr, uint32_t len, return NVME_SUCCESS; } +static void nvme_update_cq_head(NvmeCQueue *cq) +{ + if (cq->db_addr) { + pci_dma_read(&cq->ctrl->parent_obj, cq->db_addr, + &cq->head, sizeof(cq->head)); + } +} + static void nvme_post_cqes(void *opaque) { NvmeCQueue *cq = opaque; @@ -168,6 +177,8 @@ static void nvme_post_cqes(void *opaque) NvmeSQ...

...val) > } > > start_sqs = nvme_cq_full(cq) ? 1 : 0; > - cq->head = new_head; > + /* When the mapped pointer memory area is setup, we don't rely on > + * the MMIO written values to update the head pointer. */ > + if (!cq->db_addr) { > + cq->head = new_head; > + } You are still checking if (new_head >= cq->size) { return; } above. I think this is incorrect when the extension is present, and furthermore it's the only case where val is being used. If you'...

...val) > } > > start_sqs = nvme_cq_full(cq) ? 1 : 0; > - cq->head = new_head; > + /* When the mapped pointer memory area is setup, we don't rely on > + * the MMIO written values to update the head pointer. */ > + if (!cq->db_addr) { > + cq->head = new_head; > + } You are still checking if (new_head >= cq->size) { return; } above. I think this is incorrect when the extension is present, and furthermore it's the only case where val is being used. If you'...

...> > start_sqs = nvme_cq_full(cq) ? 1 : 0; > > - cq->head = new_head; > > + /* When the mapped pointer memory area is setup, we don't rely on > > + * the MMIO written values to update the head pointer. */ > > + if (!cq->db_addr) { > > + cq->head = new_head; > > + } > > You are still checking > > if (new_head >= cq->size) { > return; > } > > above. I think this is incorrect when the extension is present, and > furthermore it...

Hi Rob & Mihai, I wrote vhost-nvme patches on top of Christoph's NVMe target. vhost-nvme still uses mmio. So the guest OS can run unmodified NVMe driver. But the tests I have done didn't show competitive performance compared to virtio-blk/virtio-scsi. The bottleneck is in mmio. Your nvme vendor extension patches reduces greatly the number of MMIO writes. So I'd like to push it

Hi Rob & Mihai, I wrote vhost-nvme patches on top of Christoph's NVMe target. vhost-nvme still uses mmio. So the guest OS can run unmodified NVMe driver. But the tests I have done didn't show competitive performance compared to virtio-blk/virtio-scsi. The bottleneck is in mmio. Your nvme vendor extension patches reduces greatly the number of MMIO writes. So I'd like to push it

...start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head; >>> + /* When the mapped pointer memory area is setup, we don't rely on >>> + * the MMIO written values to update the head pointer. */ >>> + if (!cq->db_addr) { >>> + cq->head = new_head; >>> + } >> >> You are still checking >> >> if (new_head >= cq->size) { >> return; >> } >> >> above. I think this is incorrect when the extension is...

...start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head; >>> + /* When the mapped pointer memory area is setup, we don't rely on >>> + * the MMIO written values to update the head pointer. */ >>> + if (!cq->db_addr) { >>> + cq->head = new_head; >>> + } >> >> You are still checking >> >> if (new_head >= cq->size) { >> return; >> } >> >> above. I think this is incorrect when the extension is...

...= nvme_cq_full(cq) ? 1 : 0; > >>> - cq->head = new_head; > >>> + /* When the mapped pointer memory area is setup, we don't rely on > >>> + * the MMIO written values to update the head pointer. */ > >>> + if (!cq->db_addr) { > >>> + cq->head = new_head; > >>> + } > >> > >> You are still checking > >> > >> if (new_head >= cq->size) { > >> return; > >> } > >> > >> above...