linux-dev/drivers/vdpa/vdpa_sim, branch master

vdpa_sim_net: support feature provisioning

2022-10-07T13:32:40Z

This patch implements features provisioning for vdpa_sim_net. 1) validating the provisioned features to be a subset of the parent features. 2) clearing the features that is not wanted by the userspace For example: vdpasim_net: supported_classes net max_supported_vqs 3 dev_features MTU MAC CTRL_VQ CTRL_MAC_ADDR ANY_LAYOUT VERSION_1 ACCESS_PLATFORM 1) provision vDPA device with all features that are supported by the net simulator dev1: mac 00:00:00:00:00:00 link up link_announce false mtu 1500 negotiated_features MTU MAC CTRL_VQ CTRL_MAC_ADDR VERSION_1 ACCESS_PLATFORM 2) provision vDPA device with a subset of the features dev1: mac 00:00:00:00:00:00 link up link_announce false mtu 1500 negotiated_features CTRL_VQ VERSION_1 ACCESS_PLATFORM Reviewed-by: Eli Cohen Signed-off-by: Jason Wang Message-Id: <20220927074810.28627-3-jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella

vdpa_sim_blk: add support for discard and write-zeroes

2022-08-11T08:44:58Z

Expose VIRTIO_BLK_F_DISCARD and VIRTIO_BLK_F_WRITE_ZEROES features to the drivers and handle VIRTIO_BLK_T_DISCARD and VIRTIO_BLK_T_WRITE_ZEROES requests checking ranges and flags. The simulator behaves like a ramdisk, so for VIRTIO_BLK_F_DISCARD does nothing, while for VIRTIO_BLK_T_WRITE_ZEROES sets to 0 the specified region. Signed-off-by: Stefano Garzarella Message-Id: <20220811083632.77525-5-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim_blk: add support for VIRTIO_BLK_T_FLUSH

2022-08-11T08:44:58Z

The simulator behaves like a ramdisk, so we don't have to do anything when a VIRTIO_BLK_T_FLUSH request is received, but it could be useful to test driver behavior. Let's expose the VIRTIO_BLK_F_FLUSH feature to inform the driver that we support the flush command. Signed-off-by: Stefano Garzarella Message-Id: <20220811083632.77525-4-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim_blk: make vdpasim_blk_check_range usable by other requests

2022-08-11T08:44:57Z

Next patches will add handling of other requests, where will be useful to reuse vdpasim_blk_check_range(). So let's make it more generic by adding the `max_sectors` parameter, since different requests allow different numbers of maximum sectors. Let's also print the messages directly in vdpasim_blk_check_range() to avoid duplicate prints. Signed-off-by: Stefano Garzarella Message-Id: <20220811083632.77525-3-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim_blk: check if sector is 0 for commands other than read or write

2022-08-11T08:44:57Z

VIRTIO spec states: "The sector number indicates the offset (multiplied by 512) where the read or write is to occur. This field is unused and set to 0 for commands other than read or write." Signed-off-by: Stefano Garzarella Message-Id: <20220811083632.77525-2-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim: Implement suspend vdpa op

2022-08-11T08:31:15Z

Implement suspend operation for vdpa_sim devices, so vhost-vdpa will offer that backend feature and userspace can effectively suspend the device. This is a must before get virtqueue indexes (base) for live migration, since the device could modify them after userland gets them. There are individual ways to perform that action for some devices (VHOST_NET_SET_BACKEND, VHOST_VSOCK_SET_RUNNING, ...) but there was no way to perform it for any vhost device (and, in particular, vhost-vdpa). Reviewed-by: Stefano Garzarella Signed-off-by: Eugenio Pérez Message-Id: <20220810171512.2343333-5-eperezma@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim: use max_iotlb_entries as a limit in vhost_iotlb_init

2022-08-11T08:26:07Z

Commit bda324fd037a ("vdpasim: control virtqueue support") changed the allocation of iotlbs calling vhost_iotlb_init() for each address space, instead of vhost_iotlb_alloc(). With this change we forgot to use the limit we had introduced with the `max_iotlb_entries` module parameter. Fixes: bda324fd037a ("vdpasim: control virtqueue support") Cc: gautam.dawar@xilinx.com Signed-off-by: Stefano Garzarella Message-Id: <20220621151208.189959-1-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Acked-by: Eugenio Pérez

vdpa_sim_blk: set number of address spaces and virtqueue groups

2022-08-11T08:26:07Z

Commit bda324fd037a ("vdpasim: control virtqueue support") added two new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to initialize them for vdpa_sim_blk. When creating a new vdpa_sim_blk device this causes the kernel to panic in this way: $ vdpa dev add mgmtdev vdpasim_blk name blk0 BUG: kernel NULL pointer dereference, address: 0000000000000030 ... RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb] ... Call Trace: vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb] vdpasim_map_range+0x91/0xd0 [vdpa_sim] vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim] ... This happens because vdpasim->iommu[0] is not initialized when dev_attr.nas is 0. Let's fix this issue by initializing both (nas, ngroups) to 1 for vdpa_sim_blk. Fixes: bda324fd037a ("vdpasim: control virtqueue support") Cc: gautam.dawar@xilinx.com Signed-off-by: Stefano Garzarella Message-Id: <20220621151323.190431-1-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Acked-by: Eugenio Pérez

vdpa_sim_blk: call vringh_complete_iotlb() also in the error path

2022-08-11T08:26:07Z

Call vringh_complete_iotlb() even when we encounter a serious error that prevents us from writing the status in the "in" header (e.g. the header length is incorrect, etc.). The guest is misbehaving, so maybe the ring is in a bad state, but let's avoid making things worse. Acked-by: Jason Wang Signed-off-by: Stefano Garzarella Message-Id: <20220630153221.83371-4-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin

vdpa_sim_blk: limit the number of request handled per batch

2022-08-11T08:26:07Z

Limit the number of requests (4 per queue as for vdpa_sim_net) handled in a batch to prevent the worker from using the CPU for too long. Suggested-by: Eugenio Pérez Signed-off-by: Stefano Garzarella Message-Id: <20220630153221.83371-3-sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang