[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: |
Tue, 1 Mar 2016 16:19:51 +0200 |
On Tue, Mar 01, 2016 at 03:12:40PM +0100, Jan Kiszka wrote:
> 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.
Well, for example we use the q35/piix chipset with AMD CPUs,
is this very different?
> >
> >
> >> 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
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