similar to: [PATCH V2 0/3] vDPA: API for reporting IOVA range

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

Hi All: This series introduces API for reporing IOVA range. This is a must for userspace to work correclty: - for the process that uses vhost-vDPA directly to properly allocate IOVA - for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out of range - for VM(qemu), when vIOMMU is enabled, determine a valid guest address width Please review. Thanks Jason Wang (4): vdpa:

On Wed, Jun 17, 2020 at 11:29:47AM +0800, Jason Wang wrote: > This patch introduces a new ioctl for vhost-vdpa device that can > report the iova range by the device. For device that depends on > platform IOMMU, we fetch the iova range via DOMAIN_ATTR_GEOMETRY. For > devices that has its own DMA translation unit, we fetch it directly > from vDPA bus operation. > >

On Wed, Jun 17, 2020 at 11:29:47AM +0800, Jason Wang wrote: > This patch introduces a new ioctl for vhost-vdpa device that can > report the iova range by the device. For device that depends on > platform IOMMU, we fetch the iova range via DOMAIN_ATTR_GEOMETRY. For > devices that has its own DMA translation unit, we fetch it directly > from vDPA bus operation. > >

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 Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote: > This patch introduce a config op to get valid iova range from the vDPA > device. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/vdpa.h | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h > index

On Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote: > This patch introduce a config op to get valid iova range from the vDPA > device. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/vdpa.h | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h > index

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

v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not

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

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

On 2020/8/10 ??8:05, Michael S. Tsirkin wrote: > On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote: >> On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote: >>> On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote: >>>> On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote: >>>>> On Wed, Jun 17, 2020 at 11:29:44AM

On 2020/8/10 ??8:05, Michael S. Tsirkin wrote: > On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote: >> On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote: >>> On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote: >>>> On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote: >>>>> On Wed, Jun 17, 2020 at 11:29:44AM

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

Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c index 62d640327145..89854e17c3c2 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c @@ -574,6 +574,16 @@ static u32

? 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). > >

On Wed, Jun 17, 2020 at 11:29:46AM +0800, Jason Wang wrote: > In order to let userspace work correctly, get_iova_range() is a must > for the device that has its own DMA translation logic. I guess you mean for a device. However in absence of ths op, I don't see what is wrong with just assuming device can access any address. > > Signed-off-by: Jason Wang <jasowang at

Live migration of vdpa would typically require re-instate vdpa device with an idential set of configs on the destination node, same way as how source node created the device in the first place. In order to allow live migration orchestration software to export the initial set of vdpa attributes with which the device was created, it will be useful if the vdpa tool can report the config on demand