search for: qtailq_foreach

...the similar one for "if (new_ tail >= sq->size". But, I have a possible culprit. In your nvme_cq_notifier you are not doing the equivalent of: start_sqs = nvme_cq_full(cq) ? 1 : 0; cq->head = new_head; if (start_sqs) { NvmeSQueue *sq; QTAILQ_FOREACH(sq, &cq->sq_list, entry) { timer_mod(sq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500); } timer_mod(cq->timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 500); } Instead, you are just calling nvme_post_cqes, which is the equivalent of...

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello, This series fixes a few issues pointed out by Avi and Juan. Avi pointed out we should do full scatter/gather processing of guest data even if current (well-behaved) guests don't send multiple iovs per element. Juan pointed out a few migration-related bugs. In handling the migration fixes, I noticed hot-plug/unplug isn't handled perfectly for the migration case: ports are

Hello, This series fixes a few issues pointed out by Avi and Juan. Avi pointed out we should do full scatter/gather processing of guest data even if current (well-behaved) guests don't send multiple iovs per element. Juan pointed out a few migration-related bugs. In handling the migration fixes, I noticed hot-plug/unplug isn't handled perfectly for the migration case: ports are

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

...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; + } if (start_sqs) { NvmeSQueue *sq; QTAILQ_FOREACH(sq, &cq->sq_list, entry) { @@ -752,7 +828,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) return; } - sq->tail = new_tail; + /* When the mapped pointer memory area is setup, we don't rely on + * the MMIO written values...

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

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

Hi all, this is the long awaited patch series to add xen device model support in qemu; the main author is Anthony Perard. Developing this series we tried to come up with the cleanest possible solution from the qemu point of view, limiting the amount of changes to common code as much as possible. The end result still requires a couple of hooks in piix_pci but overall the impact should be very