Re: [Qemu-devel] [V6 0/4] AMD IOMMU

[David Kiarie <davidkiarie4@gmail.com>]

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
>