search for: virtio_uml

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 +- drivers/virtio/virtio_balloon.c | 2 +- drivers/virtio/virtio_ring.c | 2 +- include/linux/...

...the quirks to make it clear it is not just about the IOMMU, it's about DMA access in general. changes from v1: added patch 2 Michael S. Tsirkin (2): virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk arch/um/drivers/virtio_uml.c | 2 +- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++-- drivers/vhost/net.c | 4 ++-- drivers/vhost/vdpa.c...

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 +- drivers/virtio/virtio_balloon.c | 2 +- drivers/virtio/virtio_ring.c | 2 +- include/linux/...

...t to something > > like uvirtio. Since I really don't have other use cases for now, I just implemented the minimal stuff which work for my use case. > > > Interesting, several questions: > > 1) Are you aware of virtio vhost-user driver done by UM guys? > (arch/um/drivers/virtio_uml.c) The memory part is tricky but overall > both of you have similar target. Thanks for reminding me, I was not aware of it. The use case looks a little different: they are trying create virtio devices for user mode linux and it communicated with "host" side. My driver doesn't depen...

...e it's better to change that to something > like uvirtio. Since I really don't have other use cases for now, I just implemented the minimal stuff which work for my use case. Interesting, several questions: 1) Are you aware of virtio vhost-user driver done by UM guys? (arch/um/drivers/virtio_uml.c) The memory part is tricky but overall both of you have similar target. 2) Patch 1 said it's userspace virtio driver, which I think it is actually "userspace virtio device" 3) Need to be verbose on how the vring processing work in the commit log of patch 1 4) I'm curious whic...

...irqbypass manager vDPA: add get_vq_irq() in vdpa_config_ops vhost_vdpa: implement IRQ offloading in vhost_vdpa ifcvf: implement vdpa_config_ops.get_vq_irq() irqbypass: do not start cons/prod when failed connect vDPA: dont change vq irq after DRIVER_OK arch/um/drivers/virtio_uml.c | 2 +- arch/x86/kvm/x86.c | 12 +- drivers/crypto/virtio/virtio_crypto_core.c | 46 +- drivers/gpu/drm/virtio/virtgpu_kms.c | 16 +- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- drivers/gpu/drm/...

This is a way to create virtio based devices from user space. This is the background for this patch: We have some images works fine under qemu, we'd like to also run the same image on Google Cloud. Currently Google Cloud doesn't support virtio-vga. I had a patch to create a virtio-vga from kernel directly: https://www.spinics.net/lists/dri-devel/msg248573.html Then I got feedback from

This is a way to create virtio based devices from user space. This is the background for this patch: We have some images works fine under qemu, we'd like to also run the same image on Google Cloud. Currently Google Cloud doesn't support virtio-vga. I had a patch to create a virtio-vga from kernel directly: https://www.spinics.net/lists/dri-devel/msg248573.html Then I got feedback from