[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [PATCH v7 00/20] ARM SMMUv3 Emulation Suppor
From: |
Auger Eric |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [PATCH v7 00/20] ARM SMMUv3 Emulation Support |
Date: |
Thu, 28 Sep 2017 09:54:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Linu, Peter,
On 28/09/2017 09:13, Peter Xu wrote:
> On Thu, Sep 28, 2017 at 12:13:12PM +0530, Linu Cherian wrote:
>> Hi Eric,
>>
>>
>> On Fri Sep 01, 2017 at 07:21:03PM +0200, Eric Auger wrote:
>>> This series implements the emulation code for ARM SMMUv3.
>>>
>>> Changes since v6:
>>> - DPDK testpmd now running on guest with 2 assigned VFs
>>> - Changed the instantiation method: add the following option to
>>> the QEMU command line
>>> -device smmuv3 # for virtio/vhost use cases
>>> -device smmuv3,caching-mode # for vfio use cases (based on [1])
>>> - splitted the series into smaller patches to allow the review
>>> - the VFIO integration based on "tlbi-on-map" smmuv3 driver
>>> is isolated from the rest: last 2 patches, not for upstream.
>>> This is shipped for testing/bench until a better solution is found.
>>> - Reworked permission flag checks and event generation
>>> e testing:
>>> - in dt and ACPI modes
>>> - virtio-net-pci and vhost-net devices using dma ops with various
>>> guest page sizes [2]
>>> - assigned VFs using dma ops [3]:
>>> - AMD Overdrive and igbvf passthrough (using gsi direct mapping)
>>> - Cavium ThunderX and ixgbevf passthrough (using KVM MSI routing)
>>> - DPDK testpmd on guest running with VFIO user space drivers (2 igbvf) [3]
>>> with guest and host page size equal (4kB)
>>>
>>> Known limitations:
>>> - no VMSAv8-32 suport
>>> - no nested stage support (S1 + S2)
>>> - no support for HYP mappings
>>> - register fine emulation, commands, interrupts and errors were
>>> not accurately tested. Handling is sufficient to run use cases
>>> described above though.
>>> - interrupts and event generation not observed yet.
>>
>> While testing with vfio-pci, observed that the below two Qemu command,
>> results in two different behaviour. Is this expected by design ?
>>
>> Case 1:
>> # -device vfio-pci,host=0002:01:00.3 -device smmuv3,caching-mode
>> Here iommu is not attached to the pci bus in Qemu backend, since
>> pci_setup_iommu is not called before vfio_realize.
>>
>> Case 2:
>> # -device smmuv3,caching-mode -device vfio-pci,host=0002:01:00.3
>> This works as expected, iommu is attached to the pci bus.
>
> Not sure about SMMU, but VT-d should have similar issue - the vIOMMU
> device needs to be created before the rest of the devices.
Yes this is an expected limitation right now. I should have documented
it though. As you noticed, the pci_set_iommu() is called on virtio-iommu
realize and it relies on the fact the PCIe devices already are realized.
Maybe we could relax this constraint by calling the pci_set_iommu in a
machine init done notifier.
Thanks
Eric
>
> Now for VT-d the ordering of devices should be assured by Libvirt:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1427005
>
> For your reference only. Thanks,
>
- [Qemu-arm] [PATCH v7 19/20] hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling, (continued)
- [Qemu-arm] [PATCH v7 19/20] hw/arm/smmuv3: [not for upstream] add SMMU_CMD_TLBI_NH_VA_AM handling, Eric Auger, 2017/09/01
- [Qemu-arm] [PATCH v7 20/20] hw/arm/smmuv3: [not for upstream] Add caching-mode option, Eric Auger, 2017/09/01
- Re: [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support, Peter Maydell, 2017/09/07
- Re: [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support, Michael S. Tsirkin, 2017/09/08
- Re: [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support, Linu Cherian, 2017/09/12
- Re: [Qemu-arm] [PATCH v7 00/20] ARM SMMUv3 Emulation Support, Linu Cherian, 2017/09/28