similar to: [PATCH] vhost: fix default for vhost_iotlb

On 2020/4/16 ??12:16, Randy Dunlap wrote: > On 4/14/20 10:22 PM, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20200414: >> > on x86_64: > > ERROR: modpost: "vringh_set_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! > ERROR: modpost: "vringh_init_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! > ERROR: modpost:

On 4/14/20 10:22 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20200414: > on x86_64: ERROR: modpost: "vringh_set_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR: modpost: "vringh_init_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR: modpost: "vringh_iov_push_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR:

On 4/14/20 10:22 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20200414: > on x86_64: ERROR: modpost: "vringh_set_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR: modpost: "vringh_init_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR: modpost: "vringh_iov_push_iotlb" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined! ERROR:

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 38dd2ba72ece18ec8398c8ddd13cfb02870b0309 commit: 38dd2ba72ece18ec8398c8ddd13cfb02870b0309 [22/22] virtio/test: fix up after IOTLB changes config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce: wget

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 38dd2ba72ece18ec8398c8ddd13cfb02870b0309 commit: 38dd2ba72ece18ec8398c8ddd13cfb02870b0309 [22/22] virtio/test: fix up after IOTLB changes config: riscv-allyesconfig (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce: wget

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 076cb4adba3e2d7d3c25b72a1390b24ebfc58161 commit: 076cb4adba3e2d7d3c25b72a1390b24ebfc58161 [22/22] virtio/test: fix up after IOTLB changes config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce: wget

On Mon, Feb 10, 2020 at 11:56:08AM +0800, Jason Wang wrote: > This patch implements a software vDPA networking device. The datapath > is implemented through vringh and workqueue. The device has an on-chip > IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA > simulator driver provides dma_ops. For vhost driers, set_map() methods > of vdpa_config_ops is implemented to

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

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

This patch implements a software vDPA networking device. The datapath is implemented through vringh and workqueue. The device has an on-chip IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA simulator driver provides dma_ops. For vhost driers, set_map() methods of vdpa_config_ops is implemented to accept mappings from vhost. Currently, vDPA device simulator will loopback TX

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

This patch implements a software vDPA networking device. The datapath is implemented through vringh and workqueue. The device has an on-chip IOMMU which translates IOVA to PA. For kernel virtio drivers, vDPA simulator driver provides dma_ops. For vhost driers, set_map() methods of vdpa_config_ops is implemented to accept mappings from vhost. Currently, vDPA device simulator will loopback TX

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

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

set_dma_ops isn't available on all architectures: make ARCH=um ... drivers/vdpa/vdpa_sim/vdpa_sim.c: In function 'vdpasim_create': >> drivers/vdpa/vdpa_sim/vdpa_sim.c:324:2: error: implicit declaration of function 'set_dma_ops'; did you mean 'set_groups'? +[-Werror=implicit-function-declaration] set_dma_ops(dev, &vdpasim_dma_ops);

set_dma_ops isn't available on all architectures: make ARCH=um ... drivers/vdpa/vdpa_sim/vdpa_sim.c: In function 'vdpasim_create': >> drivers/vdpa/vdpa_sim/vdpa_sim.c:324:2: error: implicit declaration of function 'set_dma_ops'; did you mean 'set_groups'? +[-Werror=implicit-function-declaration] set_dma_ops(dev, &vdpasim_dma_ops);

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: