From mboxrd@z Thu Jan 1 00:00:00 1970 From: Muli Ben-Yehuda Subject: Re: [Qemu-devel] Direct guest device access from nested guest Date: Fri, 30 Aug 2013 08:27:58 +0300 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: =?iso-8859-1?Q?Llu=EDs?= Vilanova , Jan Kiszka , "QEMU ." , kvm To: Aaron Fabbri Return-path: Received: from mail-we0-f179.google.com ([74.125.82.179]:48641 "EHLO mail-we0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752786Ab3H3F2F (ORCPT ); Fri, 30 Aug 2013 01:28:05 -0400 Received: by mail-we0-f179.google.com with SMTP id t58so1205914wes.10 for ; Thu, 29 Aug 2013 22:28:04 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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