From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYCef-0007JW-2D for qemu-devel@nongnu.org; Mon, 12 Jul 2010 02:38:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYCdh-0008Gu-EA for qemu-devel@nongnu.org; Mon, 12 Jul 2010 02:37:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36712) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYCdh-0008Gj-7W for qemu-devel@nongnu.org; Mon, 12 Jul 2010 02:37:17 -0400 Message-ID: <4C3AB816.4070907@redhat.com> Date: Mon, 12 Jul 2010 09:37:10 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20100711180910.20121.93313.stgit@localhost6.localdomain6> <20100711180942.20121.97368.stgit@localhost6.localdomain6> <4C3A0D15.3070302@redhat.com> <1278877118.20397.103.camel@x201> In-Reply-To: <1278877118.20397.103.camel@x201> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 5/5] VFIO based device assignment List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, pugs@cisco.com On 07/11/2010 10:38 PM, Alex Williamson wrote: > >> What >> about page attributes? >> >> There are two cases: >> >> - snoop capable iommu - can use write-backed RAM, but need to enable >> snoop. BARs still need to respect page attributes. >> - older mmu - need to respect guest memory type; probably cannot be done >> without kvm. >> >> If the guest maps a BAR or RAM using write-combine memory type, can we >> reflect that? This may provide a considerable performance benefit. >> > Do we do anything about this today in kvm device assignment? Maybe it's > buried in the kernel side bits and I've missed it. I would expect that > WC mappings in the guest carry through to host virtual mappings, but > maybe we can only do that with kvm. Yes, see arch/x86/kvm/mmu.c, set_spte() calling ->get_mt_mask(). Strangely, it's qualified with tdp. Perhaps because of all of the scary errata regarding mismatching memory types for a page. > The processor side mappings are > independent of the iommu mappings since devices don't care about such > things. Thanks, > Yeah. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.