On Tue, Jun 06, 2023 at 09:29:22AM +0800, Jason Wang wrote:
On Mon, Jun 5, 2023 at 10:58 PM Stefano Garzarella <sgarzare@xxxxxxxxxx> wrote:On Mon, Jun 05, 2023 at 09:54:57AM -0400, Michael S. Tsirkin wrote: >On Mon, Jun 05, 2023 at 03:30:35PM +0200, Stefano Garzarella wrote: >> On Mon, Jun 05, 2023 at 09:00:25AM -0400, Michael S. Tsirkin wrote: >> > On Mon, Jun 05, 2023 at 02:54:20PM +0200, Stefano Garzarella wrote: >> > > On Mon, Jun 05, 2023 at 08:41:54AM -0400, Michael S. Tsirkin wrote: >> > > > On Mon, Jun 05, 2023 at 01:06:44PM +0200, Stefano Garzarella wrote: >> > > > > vhost-vdpa IOCTLs (eg. VHOST_GET_VRING_BASE, VHOST_SET_VRING_BASE) >> > > > > don't support packed virtqueue well yet, so let's filter the >> > > > > VIRTIO_F_RING_PACKED feature for now in vhost_vdpa_get_features(). >> > > > > >> > > > > This way, even if the device supports it, we don't risk it being >> > > > > negotiated, then the VMM is unable to set the vring state properly. >> > > > > >> > > > > Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") >> > > > > Cc: stable@xxxxxxxxxxxxxxx >> > > > > Signed-off-by: Stefano Garzarella <sgarzare@xxxxxxxxxx> >> > > > > --- >> > > > > >> > > > > Notes: >> > > > > This patch should be applied before the "[PATCH v2 0/3] vhost_vdpa: >> > > > > better PACKED support" series [1] and backported in stable branches. >> > > > > >> > > > > We can revert it when we are sure that everything is working with >> > > > > packed virtqueues. >> > > > > >> > > > > Thanks, >> > > > > Stefano >> > > > > >> > > > > [1] https://lore.kernel.org/virtualization/20230424225031.18947-1-shannon.nelson@xxxxxxx/ >> > > > >> > > > I'm a bit lost here. So why am I merging "better PACKED support" then? >> > > >> > > To really support packed virtqueue with vhost-vdpa, at that point we would >> > > also have to revert this patch. >> > > >> > > I wasn't sure if you wanted to queue the series for this merge window. >> > > In that case do you think it is better to send this patch only for stable >> > > branches? >> > > > Does this patch make them a NOP? >> > > >> > > Yep, after applying the "better PACKED support" series and being >> > > sure that >> > > the IOCTLs of vhost-vdpa support packed virtqueue, we should revert this >> > > patch. >> > > >> > > Let me know if you prefer a different approach. >> > > >> > > I'm concerned that QEMU uses vhost-vdpa IOCTLs thinking that the kernel >> > > interprets them the right way, when it does not. >> > > >> > > Thanks, >> > > Stefano >> > > >> > >> > If this fixes a bug can you add Fixes tags to each of them? Then it's ok >> > to merge in this window. Probably easier than the elaborate >> > mask/unmask dance. >> >> CCing Shannon (the original author of the "better PACKED support" >> series). >> >> IIUC Shannon is going to send a v3 of that series to fix the >> documentation, so Shannon can you also add the Fixes tags? >> >> Thanks, >> Stefano > >Well this is in my tree already. Just reply with >Fixes: <> >to each and I will add these tags. I tried, but it is not easy since we added the support for packed virtqueue in vdpa and vhost incrementally. Initially I was thinking of adding the same tag used here: Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") Then I discovered that vq_state wasn't there, so I was thinking of Fixes: 530a5678bc00 ("vdpa: support packed virtqueue for set/get_vq_state()") So we would have to backport quite a few patches into the stable branches. I don't know if it's worth it... I still think it is better to disable packed in the stable branches, otherwise I have to make a list of all the patches we need. Any other ideas?AFAIK, except for vp_vdpa, pds seems to be the first parent that
IIUC also vduse and snet supports packed virtqueue.
supports packed virtqueue. Users should not notice anything wrong if they don't use packed virtqueue. And the problem of vp_vdpa + packed virtqueue came since the day0 of vp_vdpa. It seems fine to do nothing I guess.
Okay, maybe I'm overthinking it, not having a specific problem I don't object, it was just a concern about uAPI. Thanks, Stefano _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
