similar to: [RFC] vhost: introduce mdev based hardware vhost backend

Details about this can be found here: https://lwn.net/Articles/750770/ What's new in this version ========================== A new VFIO device type is introduced - vfio-vhost. This addressed some comments from here: https://patchwork.ozlabs.org/cover/984763/ Below is the updated device interface: Currently, there are two regions of this device: 1) CONFIG_REGION

Details about this can be found here: https://lwn.net/Articles/750770/ What's new in this version ========================== A new VFIO device type is introduced - vfio-vhost. This addressed some comments from here: https://patchwork.ozlabs.org/cover/984763/ Below is the updated device interface: Currently, there are two regions of this device: 1) CONFIG_REGION

On 2018?04?02? 23:23, Tiwei Bie wrote: > This patch introduces a mdev (mediated device) based hardware > vhost backend. This backend is an abstraction of the various > hardware vhost accelerators (potentially any device that uses > virtio ring can be used as a vhost accelerator). Some generic > mdev parent ops are provided for accelerator drivers to support > generating mdev

On 2019/7/3 ??5:13, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > A new VFIO device type is introduced - vfio-vhost. This addressed > some comments from here: https://patchwork.ozlabs.org/cover/984763/ > > Below is the updated device interface: >

On Tue, Apr 10, 2018 at 10:52:52AM +0800, Jason Wang wrote: > On 2018?04?02? 23:23, Tiwei Bie wrote: > > This patch introduces a mdev (mediated device) based hardware > > vhost backend. This backend is an abstraction of the various > > hardware vhost accelerators (potentially any device that uses > > virtio ring can be used as a vhost accelerator). Some generic > >

On Tue, Apr 10, 2018 at 10:52:52AM +0800, Jason Wang wrote: > On 2018?04?02? 23:23, Tiwei Bie wrote: > > This patch introduces a mdev (mediated device) based hardware > > vhost backend. This backend is an abstraction of the various > > hardware vhost accelerators (potentially any device that uses > > virtio ring can be used as a vhost accelerator). Some generic > >

On Wed, Aug 28, 2019 at 01:37:12PM +0800, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > > > #1. We expose a VFIO device, so we can reuse the VFIO container/group > > based

On Wed, Aug 28, 2019 at 01:37:12PM +0800, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > > > #1. We expose a VFIO device, so we can reuse the VFIO container/group > > based

On 2019/8/28 ??1:37, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > >> #1. We expose a VFIO device, so we can reuse the VFIO container/group >> based DMA API and potentially

On 2019/8/28 ??1:37, Tiwei Bie wrote: > Details about this can be found here: > > https://lwn.net/Articles/750770/ > > What's new in this version > ========================== > > There are three choices based on the discussion [1] in RFC v2: > >> #1. We expose a VFIO device, so we can reuse the VFIO container/group >> based DMA API and potentially

On 7/7/23 12:33 AM, Jason Wang wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On Fri, Jun 30, 2023 at 8:36?AM Shannon Nelson <shannon.nelson at amd.com> wrote: >> >> From: Allen Hubbe <allen.hubbe at amd.com> >> >> When the vdpa device is reset,

v2 for internal review - heavily reworked NET_F_MAC patch, matches recent PR-68875 - reordered to put "clean and reset vqs" before "alloc-irq" to make them slightly simpler patches - other minor cleanups for simpler patches These are some fixes for device providing a MAC address, for allocating irq resources later to support vhost use, and for properly cleaning vq info

v2 for internal review - heavily reworked NET_F_MAC patch, matches recent PR-68875 - reordered to put "clean and reset vqs" before "alloc-irq" to make them slightly simpler patches - other minor cleanups for simpler patches These are some fixes for device providing a MAC address, for allocating irq resources later to support vhost use, and for properly cleaning vq info

In this commit, virtqueue operations including: set_vq_num(), set_vq_address(), set_vq_ready() and get_vq_ready() access PCI registers directly to take immediate actions. Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> --- drivers/vdpa/ifcvf/ifcvf_base.c | 58 ++++++++++++++++++++------------- drivers/vdpa/ifcvf/ifcvf_base.h | 10 +++--- drivers/vdpa/ifcvf/ifcvf_main.c | 16

This commit synchronize irqs of the virtqueues and config space in the reset routine. Thus ifcvf_stop_hw() and reset() are refactored as well. Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> --- drivers/vdpa/ifcvf/ifcvf_base.c | 41 +++++++++++++++++++++-------- drivers/vdpa/ifcvf/ifcvf_base.h | 1 + drivers/vdpa/ifcvf/ifcvf_main.c | 46 +++++---------------------------- 3 files

On Mon, May 8, 2023 at 6:05?PM Zhu Lingshan <lingshan.zhu at intel.com> wrote: > > This commit synchronize irqs of the virtqueues > and config space in the reset routine. > Thus ifcvf_stop_hw() and reset() are refactored as well. > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vdpa/ifcvf/ifcvf_base.c | 41

This commit implements a new function ifcvf_get_driver_feature() which read driver_features from virtio registers. To be less ambiguous, ifcvf_set_features() is renamed to ifcvf_set_driver_features(), and ifcvf_get_features() is renamed to ifcvf_get_dev_features() which returns the provisioned vDPA device features. Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> ---

get_vq_align returns u16 now, but that's not enough for systems/devices with 64K pages. All callers assign it to a u32 variable anyway, so let's just change the return value type to u32. Cc: "Zhu, Lingshan" <lingshan.zhu at intel.com> Reported-by: Arnd Bergmann <arnd at arndb.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On 2020/4/24 ??6:04, Zhu Lingshan wrote: > This commit implements config interrupt support > in IFC VF > > Signed-off-by: Zhu Lingshan <lingshan.zhu at intel.com> > --- > drivers/vdpa/ifcvf/ifcvf_base.c | 3 +++ > drivers/vdpa/ifcvf/ifcvf_base.h | 2 ++ > drivers/vdpa/ifcvf/ifcvf_main.c | 22 +++++++++++++++++++++- > 3 files changed, 26 insertions(+), 1

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