Re: [RFC 0/3] virtio-iommu: a paravirtualized IOMMU

On Fri, Apr 07, 2017 at 08:17:44PM +0100, Jean-Philippe Brucker wrote: > There are a number of advantages in a paravirtualized IOMMU over a full > emulation. It is portable and could be reused on different architectures. > It is easier to implement than a full emulation, with less state tracking.

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Fri, Apr 07, 2017 at 04:59:58PM -0400, Willem de Bruijn wrote: > On Fri, Apr 7, 2017 at 3:28 PM, Michael S. Tsirkin wrote: > > On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: > >> On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin > >>

[vhost:linux-next 13/26] drivers//virtio/virtio_pci_common.c:186:7: error: too few arguments to function 'vp_dev->setup_vq'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: 4293ed1476ec42e45e54f812341058d812d820a5 commit: d5edad95c2f89cced19a23713f752442b620f0e1 [13/26] virtio: add context flag to find vqs config: x86_64-randconfig-x012-201714 (attached as .config) compiler:

Re: [PATCH net-next 3/3] virtio-net: clean tx descriptors from rx napi

On Mon, Apr 03, 2017 at 01:02:13AM -0400, Willem de Bruijn wrote: > On Sun, Apr 2, 2017 at 10:47 PM, Michael S. Tsirkin wrote: > > On Sun, Apr 02, 2017 at 04:10:12PM -0400, Willem de Bruijn wrote: > >> From: Willem de Bruijn > >> > >> Amortize the cost of

[RFC PATCH kvmtool 15/15] virtio: use virtio-iommu when available

This is for development only. Virtual devices might blow up unexpectedly. In general it seems to work (slowing devices down by a factor of two of course). virtio-scsi, virtio-rng and virtio-balloon are still untested. Signed-off-by: Jean-Philippe Brucker ---

[RFC PATCH kvmtool 14/15] virtio-iommu: implement basic debug commands

Using debug printf with the virtual IOMMU can be extremely verbose. To ease debugging, add a few commands that can be sent via IPC. Format for commands is "cmd [iommu [address_space]]" (or cmd:[iommu:[address_space]]) $ lkvm debug -a -i list iommu 0 "viommu-vfio" ioas 1

[RFC PATCH kvmtool 13/15] virtio-iommu: debug via IPC

Add a new parameter to lkvm debug, '-i' or '--iommu'. Commands will be added later. For the moment, rework the debug builtin to share dump facilities with the '-d'/'--dump' parameter. Signed-off-by: Jean-Philippe Brucker --- builtin-debug.c | 8

[RFC PATCH kvmtool 12/15] vfio: add support for virtual IOMMU

Currently all passed-through devices must access the same guest-physical address space. Register an IOMMU to offer individual address spaces to devices. The way we do it is allocate one container per group, and add mappings on demand. Since guest cannot access devices unless it is attached to a

[RFC PATCH kvmtool 11/15] virtio: set VIRTIO_F_IOMMU_PLATFORM when necessary

Pass the VIRTIO_F_IOMMU_PLATFORM to tell the guest when a device is behind an IOMMU. Other feature bits in virtio do not depend on the device type and could be factored the same way. For instance our vring implementation always supports indirect descriptors (VIRTIO_RING_F_INDIRECT_DESC), so we

[RFC PATCH kvmtool 09/15] virtio: access vring and buffers through IOMMU mappings

Teach the virtio core how to access scattered vring structures. When presenting a virtual IOMMU to the guest in front of virtio devices, the virtio ring and buffers will be scattered across discontiguous guest- physical pages. The device has to translate all IOVAs to host-virtual addresses and

[RFC PATCH kvmtool 10/15] virtio-pci: translate MSIs with the virtual IOMMU

When the virtio device is behind a virtual IOMMU, the doorbell address written into the MSI-X table by the guest is an IOVA, not a physical one. When injecting an MSI, KVM needs a physical address to recognize the doorbell and the associated IRQ chip. Translate the address given by the guest into

[RFC PATCH kvmtool 07/15] virtio: factor virtqueue initialization

All virtio devices are doing the same few operations when initializing their virtqueues. Move these operations to virtio core, as we'll have to complexify vring initialization when implementing a virtual IOMMU. Signed-off-by: Jean-Philippe Brucker ---

[RFC PATCH kvmtool 08/15] virtio: add vIOMMU instance for virtio devices

Virtio devices can now opt-in to use an IOMMU, by setting the use_iommu field. None of this will work in the current state, since virtio devices still access memory linearly. A subsequent patch implements sg accesses. Signed-off-by: Jean-Philippe Brucker ---

[RFC PATCH kvmtool 06/15] irq: register MSI doorbell addresses

For passed-through devices behind a vIOMMU, we'll need to translate writes to MSI vectors. Let the IRQ code register MSI doorbells, and add a simple way for other systems to check if an address is a doorbell. Signed-off-by: Jean-Philippe Brucker --- arm/gic.c

[RFC PATCH kvmtool 05/15] iommu: describe IOMMU topology in device-trees

Add an "iommu-map" property to the PCI host controller, describing which iommus translate which devices. We describe individual devices in iommu-map, not ranges. This patch is incompatible with current mainline Linux, which requires *all* devices under a host controller to be described by the

[RFC PATCH kvmtool 04/15] Add a simple IOMMU

Add a rb-tree based IOMMU with support for map, unmap and access operations. It will be used to store mappings for virtio devices and MSI doorbells. If needed, it could also be extended with a TLB implementation. Signed-off-by: Jean-Philippe Brucker --- Makefile

[RFC PATCH kvmtool 02/15] FDT: (re)introduce a dynamic phandle allocator

The phandle allocator was removed because static values were sufficient for creating a common irqchip. With adding multiple virtual IOMMUs to the device-tree, there is a need for a dynamic allocation of phandles. Add a simple allocator that returns values above the static ones. Signed-off-by:

[RFC PATCH kvmtool 01/15] virtio: synchronize virtio-iommu headers with Linux

Pull virtio-iommu header (initial proposal) from Linux. Also add virtio_config.h because it defines VIRTIO_F_IOMMU_PLATFORM, which I'm going to need soon, and it's not provided by my toolchain. Signed-off-by: Jean-Philippe Brucker --- include/linux/virtio_config.h

[RFC PATCH kvmtool 03/15] virtio: add virtio-iommu

Implement a simple para-virtualized IOMMU for handling device address spaces in guests. Four operations are implemented: * attach/detach: guest creates an address space, symbolized by a unique identifier (IOASID), and attaches the device to it. * map/unmap: guest creates a GVA->GPA mapping in

[RFC PATCH kvmtool 00/15] Add virtio-iommu

Implement a virtio-iommu device and translate DMA traffic from vfio and virtio devices. Virtio needed some rework to support scatter-gather accesses to vring and buffers at page granularity. Patch 3 implements the actual virtio-iommu device. Adding --viommu on the command-line now inserts a

[RFC PATCH linux] iommu: Add virtio-iommu driver

The virtio IOMMU is a para-virtualized device, allowing to send IOMMU requests such as map/unmap over virtio-mmio transport. This driver should illustrate the initial proposal for virtio-iommu, that you hopefully received with it. It handle attach, detach, map and unmap requests. The bulk of the

[RFC 3/3] virtio-iommu: future work

Here I propose a few ideas for extensions and optimizations. This is all very exploratory, feel free to correct mistakes and suggest more things. I. Linux host 1. vhost-iommu 2. VFIO nested translation II. Page table sharing 1. Sharing

[RFC 2/3] virtio-iommu: device probing and operations

After the virtio-iommu device has been probed and the driver is aware of the devices translated by the IOMMU, it can start sending requests to the virtio-iommu device. The operations described here are voluntarily minimalistic, so vIOMMU devices can be as simple as possible to implement, and can

[RFC 0/3] virtio-iommu: a paravirtualized IOMMU

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices.

[RFC 1/3] virtio-iommu: firmware description of the virtual topology

Unlike other virtio devices, the virtio-iommu doesn't work independently, it is linked to other virtual or assigned devices. So before jumping into device operations, we need to define a way for the guest to discover the virtual IOMMU and the devices it translates. The host must describe the

CFP PhyCS 2017 - 4th Int.l Conf. on Physiological Computing Systems (Madrid/Spain)

SUBMISSION DEADLINE 4th International Conference on Physiological Computing Systems Submission Deadline: April 18, 2017 http://www.phycs.org July 28 - 29, 2017 Madrid, Spain. PhyCS is organized in 4 major tracks: - Devices - Methodologies and Methods - Human Factors - Applications In

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

On Fri, Apr 07, 2017 at 12:06:26PM +0200, Gerd Hoffmann wrote: > On Fr, 2017-04-07 at 11:45 +0300, Ville Syrjälä wrote: > > On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > Hmm. Maybe it's still possible to salvage something by redefining the > > > >

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

On Fr, 2017-04-07 at 11:45 +0300, Ville Syrjälä wrote: > On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > Hmm. Maybe it's still possible to salvage something by redefining the > > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > > might

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

Hi, > Hmm. Maybe it's still possible to salvage something by redefining the > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > might still result in something usable. Also at least for the virtual machine use case this doesn't buy us much. The drm drivers (at least the

Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

Hi, > > So, bigendian guests assume that DRM_FORMAT_XRGB is big endian not > > little endian. And given that the fourcc codes are used in the > > userspace/kernel API too (see DRM_IOCTL_MODE_ADDFB2) I think we can't > > change that any more ... > > Sigh. That makes mixed endian systems