On 2017年11月17日 10:01, Longpeng (Mike) wrote:
On 2017/11/16 20:04, Jason Wang wrote:
On 2017年11月16日 17:32, Longpeng (Mike) wrote:
Hi Jason,
On 2017/11/16 17:13, Jason Wang wrote:
On 2017年11月16日 17:01, Gonglei (Arei) wrote:
No, Windows guest + vhost-user/DPDK.
BTW pls see virtio spec in :
"If VIRTIO_NET_F_MQ is negotiated, each of receiveq1. . .receiveqN that will
be used SHOULD be populated
with receive buffers."
It is not mandatory that all queues must be initialized.
I think not, since it said we should fill receive buffers for each queue which
means we should initialize all queues. May Michael can clarify on this.
I think this doesn't matter, but QEMU should consider this scenario...
For example, if one queues isn't initialized (Windows guest), the vring.avail=0,
so vq->desc_phys=0, then vq->desc='a avail HVA'(which is the start addr of
pc.ram).
vq->desc_size = s = l = virtio_queue_get_desc_size(vdev, idx);
vq->desc_phys = a = virtio_queue_get_desc_addr(vdev, idx);
vq->desc = vhost_memory_map(dev, a, &l, 0);
if (!vq->desc || l != s) {
r = -ENOMEM;
goto fail_alloc_desc;
}
.....
r = vhost_virtqueue_set_addr(dev, vq, vhost_vq_index, dev->log_enabled);
if (r < 0) {
r = -errno;
goto fail_alloc;
}
Then the HVA is send to the vhost-user.
I think this is wrong, because the '0' here means guest driver doesn't init this
queues, it should not be used to calculate the HVA for this vq.
Yes, workaround is not hard if windows driver won't use the left 3 queues any
more. But we should have a complete solution. The main problem is when vhost
need to be started. For legacy device, there's no easy way to detect whether or
not a specific virtqueue is ready to be used. For modern device, we can probably
do this through queue_enable (but this is not implemented in current code).
Can we initialize the vring.desc/vring.avail/vring.used to -1, then we can
detect whether or not a specific vq is ready to be used by check the addr of its
tables is -1 or not ?
Initialize to 0 is not suitable, because we don't know whether the guest set GPA
0 or the guest not initialize this vq.
Unfortunately, it's too late to do this in spec for legacy device. (If
you look at the spec, legacy MMIO transport treat 0x0 as an illegal
value.) For modern device, we could detect this through queue_enable.
Let's wait for Yan to reply whether or not windows driver can use the
left three queues. If not, I will try to post a fix(workaround) for this
and let's consider a complete solution.
Thanks
