From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37646)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mulix@mulix.org>) id 1VFHFk-0000Oa-84
	for qemu-devel@nongnu.org; Fri, 30 Aug 2013 01:28:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mulix@mulix.org>) id 1VFHFe-0004SC-2n
	for qemu-devel@nongnu.org; Fri, 30 Aug 2013 01:28:12 -0400
Received: from mail-we0-f172.google.com ([74.125.82.172]:45393)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mulix@mulix.org>) id 1VFHFd-0004PY-St
	for qemu-devel@nongnu.org; Fri, 30 Aug 2013 01:28:05 -0400
Received: by mail-we0-f172.google.com with SMTP id t60so1206430wes.3
	for <qemu-devel@nongnu.org>; Thu, 29 Aug 2013 22:28:04 -0700 (PDT)
Sender: Muli Ben-Yehuda <mulix@mulix.org>
Date: Fri, 30 Aug 2013 08:27:58 +0300
From: Muli Ben-Yehuda <mulix@hypervisorconsulting.com>
Message-ID: <20130830052758.GL17596@needle>
References: <87sixtsxdj.fsf@fimbulvetr.bsc.es> <521E29F5.3070000@siemens.com>
	<87ppsxelbf.fsf@fimbulvetr.bsc.es> <521E3EED.2080702@siemens.com>
	<87wqn58vzk.fsf@fimbulvetr.bsc.es>
	<CAF+KLxuZqJoSKEAz+Osbh8jxZVOi+U2rNbTmMH5V3TpXn-p3xA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAF+KLxuZqJoSKEAz+Osbh8jxZVOi+U2rNbTmMH5V3TpXn-p3xA@mail.gmail.com>
Subject: Re: [Qemu-devel] Direct guest device access from nested guest
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Aaron Fabbri <ajfabbri@gmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, =?iso-8859-1?Q?Llu=EDs?= Vilanova <vilanova@ac.upc.edu>, kvm <kvm@vger.kernel.org>, "QEMU ." <qemu-devel@nongnu.org>

On Thu, Aug 29, 2013 at 03:55:20PM -0700, Aaron Fabbri wrote:

> Has anyone considered a paravirt approach?  That is:
> 
> Guest kernel:  Write a new IOMMU API back end which does KVM hypercalls.
>  Exposes VFIO to guest user processes (nested VMs) as usual.
> 
> Host kernel: KVM does things like collapse {guest_va -> guest_pa ->
> host_pa} mappings to {guest_va -> host_pa}, and call through to
> underlying IOMMU.
> 
> Opinions?

The paravirt approach can certainly work but has a couple of
drawbacks. First, you need to modify the guest kernel
(obviously). Second, frequent map/unmap calls can be very expensive,
so you probably want to relax protection somewhat and cache DMA
mappings, preferably at the guest level or at the host level[1].

Personally, I think that emulating an IOMMU is the right way to go
with current generation hardware, and can provide very reasonable
performance if you are willing to relax protection[2].

[1] http://www.mulix.org/pubs/iommu/dmamapping.pdf
[2] http://www.mulix.org/pubs/iommu/viommu.pdf

Cheers,
Muli