From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 4/4][VTD] vt-d specific files in KVM Date: Tue, 10 Jun 2008 10:24:06 -0500 Message-ID: <484E9C96.7090502@codemonkey.ws> 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> <20080610151526.GG6702@il.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Kay, Allen M" , kvm@vger.kernel.org, Amit Shah , Ben-Ami Yassour1 , Avi Kivity , Chris Wright , "Han, Weidong" To: Muli Ben-Yehuda Return-path: Received: from yx-out-2324.google.com ([74.125.44.30]:36700 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752889AbYFJPYX (ORCPT ); Tue, 10 Jun 2008 11:24:23 -0400 Received: by yx-out-2324.google.com with SMTP id 31so256471yxl.1 for ; Tue, 10 Jun 2008 08:24:22 -0700 (PDT) In-Reply-To: <20080610151526.GG6702@il.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Muli Ben-Yehuda wrote: > 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). > If you add the MMIO page to the IOMMU table, then the behavior is going to be identical to what occurs on bare metal which IMHO is a good thing. Why jump through hoops to change what may or may not be an error condition instead of letting the natural error behavior happen? There may be some weird piece of hardware that relies on this behavior out there. >> 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). > There is no such thing as an MMIO slot. All you would need to do is mmap(phys_ram_base + GPA, "/sys/bus/pci/.../region/0", MAP_SHARED | MAP_FIXED) and you'd have a mixed slot assuming GPA was within an existing RAM slot. Without MMU-notifiers, you'd have to do this before the guest started. With MMU-notifiers, you can do this during execution of the guest. Regards, Anthony Liguori > Cheers, > Muli >