similar to: [PATCH v2 0/2] virtio: modernize DMA quirks

Rename the bit to match latest virtio spec. Add a compat macro to avoid breaking existing userspace. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/um/drivers/virtio_uml.c | 2 +- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++-- drivers/vhost/net.c | 4 ++-- drivers/vhost/vdpa.c | 2 +-

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c

Now that the corresponding feature bit has been renamed, rename the quirk too - it's about special ways to do DMA, not necessarily about the IOMMU. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/virtio/virtio_ring.c | 2 +- include/linux/virtio_config.h

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:

Rename the bit to match latest virtio spec. Add a compat macro to avoid breaking existing userspace. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/um/drivers/virtio_uml.c | 2 +- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++-- drivers/vhost/net.c | 4 ++-- drivers/vhost/vdpa.c | 2 +-

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++ drivers/gpu/drm/virtio/virtgpu_object.c | 49

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++ drivers/gpu/drm/virtio/virtgpu_object.c | 49

Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +- drivers/gpu/drm/virtio/virtgpu_object.c | 55

On Tue, Sep 08, 2020 at 08:47:41AM +0200, Gerd Hoffmann wrote: > These days dma ops can be overridden per device, and the virtio core "can be overridden" or "are"? The comment above vring_use_dma_api() suggests that's not yet done. If that's wrong then I think updating the comment would be really good. -Daniel > uses that to handle the dma quirks transparently

Now that many more architectures build vhost, a couple of these (um, and arm with deprecated oabi) have reported build failures with randconfig, however fixes for that need a bit more discussion/testing and will be merged separately. Not a regression - these previously simply didn't have vhost at all. Also, there's some DMA API code in the vdpa simulator is hacky - if no solution surfaces

Now that many more architectures build vhost, a couple of these (um, and arm with deprecated oabi) have reported build failures with randconfig, however fixes for that need a bit more discussion/testing and will be merged separately. Not a regression - these previously simply didn't have vhost at all. Also, there's some DMA API code in the vdpa simulator is hacky - if no solution surfaces

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

The following changes since commit ceaa837f96adb69c0df0397937cd74991d5d821a: Linux 6.2-rc8 (2023-02-12 14:10:17 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to deeacf35c922da579637f5db625af20baafc66ed: vdpa/mlx5: support device features provisioning (2023-02-20 19:27:00 -0500)

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

On Thu, Mar 02, 2023 at 11:26:53AM +0800, Jason Wang wrote: > On Thu, Mar 2, 2023 at 11:24?AM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > On Thu, 2 Mar 2023 11:05:26 +0800, Jason Wang <jasowang at redhat.com> wrote: > > > On Thu, Mar 2, 2023 at 10:24?AM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > > > > > > > On

OK, some patches in the series add buggy code which is then fixed by follow-up patches, but none of the bugs fixed are severe regressions on common configs (e.g. compiler warnings, lockdep/rt errors, or bugs in new drivers). So I thought it's more important to preserve the credit for the fixes. I had to pull 5 patches from git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux mlx5-next

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> ---