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 19:07:15 +0300 Message-ID: <20080610160715.GA7197@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> <20080610151526.GG6702@il.ibm.com> <484E9C96.7090502@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 mtagate5.de.ibm.com ([195.212.29.154]:51164 "EHLO mtagate5.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249AbYFJQID (ORCPT ); Tue, 10 Jun 2008 12:08:03 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id m5AG7MK3420818 for ; Tue, 10 Jun 2008 16:07:22 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5AG7MAr4157486 for ; Tue, 10 Jun 2008 18:07:22 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5AG7L5g001038 for ; Tue, 10 Jun 2008 18:07:22 +0200 Content-Disposition: inline In-Reply-To: <484E9C96.7090502@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jun 10, 2008 at 10:24:06AM -0500, Anthony Liguori wrote: > 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. One potential outcome of this behaviour on bare metal---which has been observed!---is a machine check. Letting the guest machine check the host is not a good thing. > 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. That doesn't happen with the current code base, but color me convinced: we'll just continue checking gfns one by one when mapping them into the IOMMU page tables, skipping any non-ram gfns. Cheers, Muli