From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abENr-0001GH-Ov for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:32:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abENo-0007EG-Kt for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:32:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abENo-0007E3-FQ for qemu-devel@nongnu.org; Wed, 02 Mar 2016 16:32:36 -0500 Date: Wed, 2 Mar 2016 23:32:32 +0200 From: "Michael S. Tsirkin" Message-ID: <20160302233206-mutt-send-email-mst@redhat.com> References: <1456078260-6669-1-git-send-email-davidkiarie4@gmail.com> <20160301134419-mutt-send-email-mst@redhat.com> <56D59DA3.3040002@siemens.com> <56D75867.2090801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D75867.2090801@gmail.com> Subject: Re: [Qemu-devel] [V6 0/4] AMD IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Kiarie Cc: marcel@redhat.com, Jan Kiszka , valentine.sinitsyn@gmail.com, qemu-devel@nongnu.org On Thu, Mar 03, 2016 at 12:17:27AM +0300, David Kiarie wrote: > > > 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 ? Why not :) > > > >Jan > >