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.
>
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
> >> wrote:
> >> > On Sun, Apr 02, 2017 at
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: gcc-
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 virtual interrupts by doing both rx and t
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
---
virtio/core.c | 3 +++
1 file changed
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
devic
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 +++-
include/kvm/builtin-debug.h
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 co
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 cou
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 gath
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 a
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
---
include/kvm/virtio.h | 16 +---
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
---
include/kvm/virtio-mmio.h | 1 +
inc
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 | 4
include/kvm/irq.h
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 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| 1 +
include/kvm/i
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: Jean
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 | 74 ++
i
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 an
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 virtua
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 c
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 IOMM
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 be
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.
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 relat
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 C
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
> > > > BIG_END
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
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 virtua
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 on
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 pre
31 matches
Mail list logo