[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [V6 0/4] AMD IOMMU
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [V6 0/4] AMD IOMMU |
Date: |
Wed, 2 Mar 2016 23:32:32 +0200 |
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
> >
Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Jan Kiszka, 2016/03/01
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Michael S. Tsirkin, 2016/03/01
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Jan Kiszka, 2016/03/01
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Michael S. Tsirkin, 2016/03/01
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Jan Kiszka, 2016/03/01
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU, Michael S. Tsirkin, 2016/03/01
Re: [Qemu-devel] [V6 0/4] AMD IOMMU, David Kiarie, 2016/03/02
- Re: [Qemu-devel] [V6 0/4] AMD IOMMU,
Michael S. Tsirkin <=