similar to: [PATCH V3 0/5] vDPA support

Displaying 20 results from an estimated 8000 matches similar to: "[PATCH V3 0/5] vDPA support"

2020 Feb 20
5
[PATCH V4 0/5] vDPA support
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
2020 Feb 10
9
[PATCH V2 0/5] vDPA support
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
2023 Mar 02
8
[PATCH v2 0/8] vdpa_sim: add support for user VA
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
2023 Mar 21
5
[PATCH v3 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
2023 Apr 04
9
[PATCH v5 0/9] 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
2023 Mar 23
1
[PATCH v3 4/8] vringh: support VA with iotlb
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
2023 Mar 21
1
[PATCH v3 4/8] vringh: support VA with iotlb
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
2020 Sep 24
30
[RFC PATCH 00/24] Control VQ support in vDPA
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
2020 Sep 24
30
[RFC PATCH 00/24] Control VQ support in vDPA
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
2023 Mar 21
3
[PATCH v3 5/8] vdpa_sim: make devices agnostic for work management
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 ++-
2023 Mar 02
1
[PATCH v2 7/8] vdpa_sim: replace the spinlock with a mutex to protect the state
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.
2020 Apr 01
2
[PATCH] virtio/test: fix up after IOTLB changes
Allow building vringh without IOTLB (that's the case for userspace builds, will be useful for CAIF/VOD down the road too). Update for API tweaks. Don't include vringh with kernel builds. Cc: Jason Wang <jasowang at redhat.com> Cc: Eugenio P?rez <eperezma at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/test.c | 4 ++--
2020 Apr 01
2
[PATCH] virtio/test: fix up after IOTLB changes
Allow building vringh without IOTLB (that's the case for userspace builds, will be useful for CAIF/VOD down the road too). Update for API tweaks. Don't include vringh with kernel builds. Cc: Jason Wang <jasowang at redhat.com> Cc: Eugenio P?rez <eperezma at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/test.c | 4 ++--
2020 Apr 02
1
[PATCH v2] virtio/test: fix up after IOTLB changes
Allow building vringh without IOTLB (that's the case for userspace builds, will be useful for CAIF/VOD down the road too). Update for API tweaks. Don't include vringh with userspace builds. Cc: Jason Wang <jasowang at redhat.com> Cc: Eugenio P?rez <eperezma at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- changes from v1: use IS_REACHEABLE to
2020 Aug 05
3
[PATCH v2 22/24] vdpa_sim: fix endian-ness of config space
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:
2020 Aug 05
3
[PATCH v2 22/24] vdpa_sim: fix endian-ness of config space
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:
2020 Apr 02
1
[PATCH] virtio/test: fix up after IOTLB changes
On Thu, Apr 02, 2020 at 12:01:56PM +0800, Jason Wang wrote: > > On 2020/4/2 ??12:51, Michael S. Tsirkin wrote: > > Allow building vringh without IOTLB (that's the case for userspace > > builds, will be useful for CAIF/VOD down the road too). > > Update for API tweaks. > > Don't include vringh with kernel builds. > > > I'm not quite sure we need
2020 Jul 15
2
[PATCH RFC don't apply] vdpa_sim: endian-ness for config space
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
2020 Jul 15
2
[PATCH RFC don't apply] vdpa_sim: endian-ness for config space
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
2020 Aug 21
9
[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. Changes from V1: - do not mandate