From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abE9l-0003Wq-8d for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:18:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abE9i-0003nt-0x for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:18:05 -0500 Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:35234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abE9h-0003no-Pq for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:18:01 -0500 Received: by mail-wm0-x234.google.com with SMTP id l68so104607932wml.0 for ; Wed, 02 Mar 2016 13:18:01 -0800 (PST) References: <1456078260-6669-1-git-send-email-davidkiarie4@gmail.com> <20160301134419-mutt-send-email-mst@redhat.com> <56D59DA3.3040002@siemens.com> From: David Kiarie Message-ID: <56D75867.2090801@gmail.com> Date: Thu, 3 Mar 2016 00:17:27 +0300 MIME-Version: 1.0 In-Reply-To: <56D59DA3.3040002@siemens.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [V6 0/4] AMD IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , "Michael S. Tsirkin" Cc: marcel@redhat.com, valentine.sinitsyn@gmail.com, qemu-devel@nongnu.org On 01/03/16 16:48, Jan Kiszka wrote: > On 2016-03-01 14:07, Michael S. Tsirkin wrote: >> On Sun, Feb 21, 2016 at 09:10:56PM +0300, David Kiarie wrote: >>> Hello there, >>> >>> Repost, AMD IOMMU patches version 6. >>> >>> Changes since version 5 >>> -Fixed macro formating issues >>> -changed occurences of IO MMU to IOMMU for consistency >>> -Fixed capability registers duplication >>> -Rebased to current master >>> >>> David Kiarie (4): >>> hw/i386: Introduce AMD IOMMU >>> hw/core: Add AMD IOMMU to machine properties >>> hw/i386: ACPI table for AMD IOMMU >>> hw/pci-host: Emulate AMD IOMMU >> I went over AMD IOMMU spec. >> I'm concerned that it appears that there's no chance for it to >> work correctly if host caches invalid PTE entries. >> >> The spec vaguely discusses write-protecting such PTEs but >> that would be very complex if it can be made to work at all. >> >> This means that this can't work with e.g. VFIO. >> It can only work with emulated devices. > You mean it can't work if we program a real IOMMU (for VFIO) with > translated data from the emulated one but cannot track any updates of > the related page tables because the guest is not required to issue > traceable flush requests? Hmm, too bad. > >> OTOH VTD can easily support PTE shadowing by setting a flag. > Do you mean RWBF=1 in the CAP register? Given that "Newer hardware > implementations are expected to NOT require explicit software flushing > of write buffers and report RWBF=0 in the Capability register", we may > eventually run into guests that no longer check that flag if we expose > something that looks like a "newer" implementation. > > However, this flag is not set right now in our VT-d model. > >> I'd like us to find some way to avoid possibility >> of user error creating a configuration mixing e.g. >> vfio with the amd iommu. >> >> I'm not sure how to do this. >> >> Any idea? > There is likely no way around write-protecting the IOMMU page tables (in > KVM mode) once we evaluated and cached them somewhere. For now, I would > simply deny vfio while an IOMMU is active on x86. Should I implement this, in the meantime ? > > Jan >