-----Original Message-----
From: Jason Wang [mailto:jasowang@redhat.com]
Sent: Thursday, January 6, 2022 10:34 AM
To: Michael S. Tsirkin<mst@redhat.com>
Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
<longpeng2@huawei.com>; Stefan Hajnoczi<stefanha@redhat.com>; Stefano
Garzarella<sgarzare@redhat.com>; Cornelia Huck<cohuck@redhat.com>; pbonzini
<pbonzini@redhat.com>; Gonglei (Arei)<arei.gonglei@huawei.com>; Yechuan
<yechuan@huawei.com>; Huangzhichao<huangzhichao@huawei.com>; qemu-devel
<qemu-devel@nongnu.org>
Subject: Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa
On Wed, Jan 5, 2022 at 8:26 PM Michael S. Tsirkin<mst@redhat.com> wrote:
On Wed, Jan 05, 2022 at 05:09:07PM +0800, Jason Wang wrote:
On Wed, Jan 5, 2022 at 4:37 PM Longpeng (Mike, Cloud Infrastructure
Service Product Dept.)<longpeng2@huawei.com> wrote:
-----Original Message-----
From: Jason Wang [mailto:jasowang@redhat.com]
Sent: Wednesday, January 5, 2022 3:54 PM
To: Michael S. Tsirkin<mst@redhat.com>
Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
<longpeng2@huawei.com>; Stefan Hajnoczi<stefanha@redhat.com>; Stefano
Garzarella<sgarzare@redhat.com>; Cornelia Huck<cohuck@redhat.com>;
pbonzini
<pbonzini@redhat.com>; Gonglei (Arei)<arei.gonglei@huawei.com>; Yechuan
<yechuan@huawei.com>; Huangzhichao<huangzhichao@huawei.com>;
qemu-devel
<qemu-devel@nongnu.org>
Subject: Re: [RFC 02/10] vhost: add 3 commands for vhost-vdpa
On Wed, Jan 5, 2022 at 3:02 PM Michael S. Tsirkin<mst@redhat.com> wrote:
On Wed, Jan 05, 2022 at 12:35:53PM +0800, Jason Wang wrote:
On Wed, Jan 5, 2022 at 8:59 AM Longpeng(Mike)<longpeng2@huawei.com>
wrote:
From: Longpeng<longpeng2@huawei.com>
To support generic vdpa deivce, we need add the following ioctls:
- GET_VECTORS_NUM: the count of vectors that supported
Does this mean MSI vectors? If yes, it looks like a layer violation:
vhost is transport independent.
Well*guest* needs to know how many vectors device supports.
I don't think there's a way around that. Do you?
We have VHOST_SET_VRING/CONFIG_CALL which is per vq. I think we can
simply assume #vqs + 1?
Otherwise guests will at best be suboptimal.
And it reveals device implementation
details which block (cross vendor) migration.
Thanks
Not necessarily, userspace can hide this from guest if it
wants to, just validate.
If we can hide it at vhost/uAPI level, it would be even better?
Not only MSI vectors, but also queue-size, #vqs, etc.
MSI is PCI specific, we have non PCI vDPA parent e.g VDUSE/simulator/mlx5
And it's something that is not guaranteed to be not changed. E.g some
drivers may choose to allocate MSI during set_status() which can fail
for various reasons.
Maybe the vhost level could expose the hardware's real capabilities
and let the userspace (QEMU) do the hiding? The userspace know how
to process them.
#MSI vectors is much more easier to be mediated than queue-size and #vqs.
For interrupts, we've already had VHOST_SET_X_KICK, we can keep
allocating eventfd based on #MSI vectors to make it work with any
number of MSI vectors that the virtual device had.
Right but if hardware does not support so many then what?
Just fail?
Or just trigger the callback of vqs that shares the vector.