On 2016-03-01 14:55, Michael S. Tsirkin wrote: > On Tue, Mar 01, 2016 at 02:48:19PM +0100, 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. > > Hopefully not, if that happens we'll have to do a PV IOMMU :)
Please not. > >> 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. > > Well for one, it's possible to use vt-d and not amd iommu. That would lead to nice combos of AMD CPUs with VT-d IOMMU. While it may be possible, I wouldn't rely on guests having tested that combination very well. > > >> For now, I would >> simply deny vfio while an IOMMU is active on x86. >> >> Jan > > With the caveat that we should be able to do it per iommu type > down the road. Right now, it's type-independent. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
