[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [RFC 1/4] vdpa: add VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK flag
On Wed, May 24, 2023 at 6:10âPM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, May 24, 2023 at 12:06:47PM +0800, Jason Wang wrote: > > On Tue, May 23, 2023 at 1:55âPM Eugenio Perez Martin > > <eperezma@redhat.com> wrote: > > > > > > On Mon, May 22, 2023 at 11:22âPM Shannon Nelson <shannon.nelson@amd.com> wrote: > > > > > > > > On 5/22/23 1:07 PM, Eugenio Perez Martin wrote: > > > > > > > > > > On Mon, May 22, 2023 at 9:23âPM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > >> > > > > >> On Mon, May 22, 2023 at 08:57:27PM +0200, Eugenio PÃrez wrote: > > > > >>> Signed-off-by: Eugenio PÃrez <eperezma@redhat.com> > > > > >>> --- > > > > >>> include/uapi/linux/vhost_types.h | 2 ++ > > > > >>> 1 file changed, 2 insertions(+) > > > > >>> > > > > >>> diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h > > > > >>> index c5690a8992d8..a1b316f49b38 100644 > > > > >>> --- a/include/uapi/linux/vhost_types.h > > > > >>> +++ b/include/uapi/linux/vhost_types.h > > > > >>> @@ -165,5 +165,7 @@ struct vhost_vdpa_iova_range { > > > > >>> #define VHOST_BACKEND_F_SUSPEND 0x4 > > > > >>> /* Device can be resumed */ > > > > >>> #define VHOST_BACKEND_F_RESUME 0x5 > > > > >>> +/* Device can enable virtqueues after DRIVER_OK */ > > > > >> > > > > >> A bit more detail on what does this mean? > > > > >> It's normally driver that enables VQs not device itself ... > > > > >> > > > > > > > > > > I agree, it is not well explained. > > > > > > > > > > What about "Device supports the driver to enable virtqueues after DRIVER_OK"? > > > > > > > > > >>> +#define VHOST_BACKEND_F_ENABLE_AFTER_DRIVER_OK 0x6 > > > > > > > > Does this mean it is possible only after DRIVER_OK, or does it mean in > > > > addition to before DRIVER_OK? It isn't clear to me. > > > > > > > > Maybe something like > > > > "Device supports virtqueue enable only after DRIVER_OK" > > > > or > > > > "Device supports virtqueue enable both before and after DRIVER_OK" > > > > > > > > > > I agree too, > > > > > > With the previous suggestion it would be: > > > > > > "Device supports the driver to enable virtqueues both before and after > > > DRIVER_OK" > > > > Btw, I think it might be worth clarifying whether or not this is > > supported by the current virtio spec. Spec seems to be unclear on > > this: > > > > 1) The driver MUST NOT write a 0 to queue_enable. > > 2) if reset is support, driver can wrote 1 to re-enable a virtqueue > > > > But it doesn't say if the driver can write 1 after DRIVER_OK without reset. > > > > Thanks > > I don't think it can. Do any drivers do this? I don't know. But the spec is unclear in this. And Qemu seems to support this which is probably a side effect since vq reset. case VIRTIO_PCI_COMMON_Q_ENABLE: if (val == 1) { virtio_queue_set_num(vdev, vdev->queue_sel, proxy->vqs[vdev->queue_sel].num); virtio_queue_set_rings(vdev, vdev->queue_sel, ((uint64_t)proxy->vqs[vdev->queue_sel].desc[1]) << 32 | proxy->vqs[vdev->queue_sel].desc[0], ((uint64_t)proxy->vqs[vdev->queue_sel].avail[1]) << 32 | proxy->vqs[vdev->queue_sel].avail[0], ((uint64_t)proxy->vqs[vdev->queue_sel].used[1]) << 32 | proxy->vqs[vdev->queue_sel].used[0]); proxy->vqs[vdev->queue_sel].enabled = 1; proxy->vqs[vdev->queue_sel].reset = 0; virtio_queue_enable(vdev, vdev->queue_sel); We need either 1) relax the spec to allow this feature 2) or fix the qemu (not sure if it's too late to do this) and have a new feature for queue_enable after DRIVER_OK Thanks > > > > > > > > > > Does it look better? > > > > > > Thanks! > > > > > > > sln > > > > > > > > > > > > >>> > > > > >>> #endif > > > > >>> -- > > > > >>> 2.31.1 > > > > >> > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]