similar to: [PATCH v2 0/8] vdpa_sim: add support for user VA

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

Let's move work management inside the vdpa_sim core. This way we can easily change how we manage the works, without having to change the devices each time. Acked-by: Eugenio P??rez Martin <eperezma at redhat.com> Acked-by: Jason Wang <jasowang at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++-

On Thu, Mar 2, 2023 at 7:35?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: false) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the

? 2023/3/21 23:48, Stefano Garzarella ??: > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the bus supports user VA > (e.g. vhost-vdpa). > >

vDPA supports the possibility to use user VA in the iotlb messages. So, let's add support for user VA in vringh to use it in the vDPA simulators. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - refactored avoiding code duplication [Eugenio] v2: - replace kmap_atomic() with kmap_local_page() [see previous patch] - fix cast warnings when

On Tue, Mar 21, 2023 at 11:43?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > vDPA supports the possibility to use user VA in the iotlb messages. > So, let's add support for user VA in vringh to use it in the vDPA > simulators. > > Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> > --- > > Notes: > v3: > - refactored

On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the

The spinlock we use to protect the state of the simulator is sometimes held for a long time (for example, when devices handle requests). This also prevents us from calling functions that might sleep (such as kthread_flush_work() in the next patch), and thus having to release and retake the lock. For these reasons, let's replace the spinlock with a mutex that gives us more flexibility.

This series is mainly for testing live migration between 2 vdpa_sim_blk devices. The first patch is preparation and moves the buffer allocation into devices, the second patch adds the `shared_buffer_mutex` parameter to vdpa_sim_blk to use the same ramdisk for all devices. Tested with QEMU v8.0.0-rc2 in this way: modprobe vhost_vdpa modprobe vdpa_sim_blk shared_backend=true vdpa dev add mgmtdev

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

Hi all: This is an update version of vDPA support in kernel. vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single

Hi all: This is an updated version of kernel support for vDPA device. Various changes were made based on the feedback since last verion. One major change is to drop the sysfs API and leave the management interface for future development, and introudce the incremental DMA bus operations. Please see changelog for more information. The work on vhost, IFCVF (intel VF driver for vDPA) and qemu is

On Thu, Mar 23, 2023 at 11:42:07AM +0800, Jason Wang wrote: >On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> The new "use_va" module parameter (default: true) is used in >> vdpa_alloc_device() to inform the vDPA framework that the device >> supports VA. >> >> vringh is initialized to use VA only when

When the user call VHOST_SET_OWNER ioctl and the vDPA device has `use_va` set to true, let's call the bind_mm callback. In this way we can bind the device to the user address space and directly use the user VA. The unbind_mm callback is called during the release after stopping the device. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - added `case

On Tue, Mar 21, 2023 at 11:42?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > When the user call VHOST_SET_OWNER ioctl and the vDPA device > has `use_va` set to true, let's call the bind_mm callback. > In this way we can bind the device to the user address space > and directly use the user VA. > > The unbind_mm callback is called during the release after

On Fri, Mar 24, 2023 at 10:54:39AM +0800, Jason Wang wrote: >On Thu, Mar 23, 2023 at 5:50?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> On Thu, Mar 23, 2023 at 11:42:07AM +0800, Jason Wang wrote: >> >On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> >> >> The new "use_va"

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > VDPA sim accesses config space as native endian - this is > wrong since it's a modern device and actually uses LE. > > It only supports modern guests so we could punt and > just force LE, but let's use the full virtio APIs since people > tend to copy/paste code, and this is not data path anyway. > > Signed-off-by:

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > VDPA sim accesses config space as native endian - this is > wrong since it's a modern device and actually uses LE. > > It only supports modern guests so we could punt and > just force LE, but let's use the full virtio APIs since people > tend to copy/paste code, and this is not data path anyway. > > Signed-off-by:

VDPA sim stores config space as native endian, but that is wrong: modern guests expect LE. I coded up the following to fix it up, but it is wrong too: vdpasim_create is called before guest features are known. So what should we do? New ioctl to specify the interface used? More ideas? Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.c | 22