From mboxrd@z Thu Jan 1 00:00:00 1970 From: Muli Ben-Yehuda Subject: Re: [PATCH 4/4][VTD] vt-d specific files in KVM Date: Tue, 10 Jun 2008 18:15:26 +0300 Message-ID: <20080610151526.GG6702@il.ibm.com> References: <1FE6DD409037234FAB833C420AA843EC018831D5@orsmsx424.amr.corp.intel.com> <20080610102759.GG7307@il.ibm.com> <484E8EFC.10007@codemonkey.ws> <20080610145638.GF6702@il.ibm.com> <484E9795.4010409@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Kay, Allen M" , kvm@vger.kernel.org, Amit Shah , Ben-Ami Yassour1 , Avi Kivity , Chris Wright , "Han, Weidong" To: Anthony Liguori Return-path: Received: from mtagate3.de.ibm.com ([195.212.29.152]:44255 "EHLO mtagate3.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752164AbYFJPPe (ORCPT ); Tue, 10 Jun 2008 11:15:34 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m5AFFX4f246586 for ; Tue, 10 Jun 2008 15:15:33 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5AFFWJr3043362 for ; Tue, 10 Jun 2008 17:15:32 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5AFFVA6012404 for ; Tue, 10 Jun 2008 17:15:32 +0200 Content-Disposition: inline In-Reply-To: <484E9795.4010409@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jun 10, 2008 at 10:02:45AM -0500, Anthony Liguori wrote: > Why? Wouldn't MMIO pages have to be mapped in the VT-d page table > in order to support pass-through? It certainly can't hurt, can it? By MMIO pages we refer to pages which are mapped (or can mapped) to device MMIO regions. In other words, they are only relevant for host memory accesses. VT-d mappings are used for *device* memory accesses. I can't think of a good reason for a device to try to DMA to such a page (where would the DMA end? There is no backing RAM), hence the principal of least surprise says that we shouldn't map such pages in the IOMMU page tables so that *if* the device tries to DMA to them we will take an IOMMU fault rather than fail silently or machine check (I've seen both happen with DMAs to MMIO regions). > At any rate, looking at the code again, the else clause is: > >> + printk(KERN_DEBUG "kvm_iommu_map_page:" >> + "invalid pfn=%lx\n", pfn); >> + return 0; > > > Which looks like error handling to me. You are right, that snippet should be fixed to just skip non-RAM gfns. > I don't think it's at all safe to assume that a slot is either > entirely MMIO or entirely RAM. You could very easily construct a > slot that's a mix of both so if this is an attempt to skip MMIO > slots, it's broken. How would suc a slot be constructed with the current code base? (Note that you need Ben's direct MMIO patches to create an MMIO slot). Cheers, Muli