On Wed, May 24, 2023 at 6:10 PM Michael S. Tsirkin <[email protected]> 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
> > <[email protected]> wrote:
> > >
> > > On Mon, May 22, 2023 at 11:22 PM Shannon Nelson <[email protected]>
> > > wrote:
> > > >
> > > > On 5/22/23 1:07 PM, Eugenio Perez Martin wrote:
> > > > >
> > > > > On Mon, May 22, 2023 at 9:23 PM Michael S. Tsirkin <[email protected]>
> > > > > wrote:
> > > > >>
> > > > >> On Mon, May 22, 2023 at 08:57:27PM +0200, Eugenio Pérez wrote:
> > > > >>> Signed-off-by: Eugenio Pérez <[email protected]>
> > > > >>> ---
> > > > >>> 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
> > > > >>
> > > > >
> > > >
> > >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
