Re: [Qemu-devel] [PATCH v2 0/9] SMMUv3 Emulation support

[Auger Eric]

Hi Edgar,

removing Prem's address which is not valid anymore

On 27/03/2017 13:44, Edgar E. Iglesias wrote:
> On Wed, Mar 08, 2017 at 06:46:13PM +0100, Auger Eric wrote:
>> Hi,
>> On 22/08/2016 18:17, Prem Mallappa wrote:
>>> v1 -> v2:
>>>     - Adopted review comments from Eric Auger
>>>             - Make SMMU_DPRINTF to internally call qemu_log
>>>                 (since translation requests are too many, we need control
>>>                  on the type of log we want)
>>>             - SMMUTransCfg modified to suite simplicity
>>>             - Change RegInfo to uint64 register array
>>>             - Code cleanup
>>>             - Test cleanups
>>>     - Reshuffled patches
>>>
>>> RFC -> v1:
>>>     - As per SMMUv3 spec 16.0 (only is_ste_consistant() is noticeable)
>>>     - Reworked register access/update logic
>>>     - Factored out translation code for
>>>             - single point bug fix
>>>             - sharing/removal in future
>>>     - (optional) Unit tests added, with PCI test device
>>>             - S1 with 4k/64k, S1+S2 with 4k/64k
>>>             - (S1 or S2) only can be verified by Linux 4.7 driver
>>>     - (optional) Priliminary ACPI support
>>>
>>> RFC:
>>>     - Implements SMMUv3 spec 11.0
>>>     - Supported for PCIe devices, 
>>>     - Command Queue and Event Queue supported
>>>     - LPAE only, S1 is supported and Tested, S2 not tested
>>>     - BE mode Translation not supported
>>>     - IRQ support (legacy, no MSI)
>>>     - Tested with DPDK and e1000 
>>>
>>> Patch 1: Add new log type for IOMMU transactions
>>>
>>> Patch 2: Adds support in virt.c to create both SMMUv3 device and dts entries
>>>
>>> Patch 2: Adds SMMUv3 model to QEMU
>>>     Multiple files, big ones, translate functionality is split across to
>>>     accomodate SMMUv2 model, and to remove when common translation feature
>>>     (if) becomes available.
>>>
>>> Patch 3: Adds SMMU build support
>>>
>>> Patch 4: Some devicetree function to add support for SMMU's multiple 
>>> interrupt
>>>      assignment with names
>>>
>>> << optional patches >>
>>> Optional patches are posted for completeness or for those who wants to test.
>>>
>>> Patch 5: A simple PCI device which does DMA from 'src' to 'dst' given
>>>      src_addr, dst_addr and size, and is used by unit test, uses
>>>      pci_dma_read and pci_dma_write in a crude way but serves the purpose.
>>>
>>> Patch 6: Current libqos PCI helpers are x86 only, this addes a generic 
>>> interface
>>>
>>> Patch 7: Unit tests for SMMU, 
>>>             - initializes SMMU device 
>>>             - initializes Test device
>>>             - allocates page tables 1:1 mapping va == pa
>>>             - allocates STE/CD accordingly for S1, S2, S1+S2
>>>             - initiates DMA via PCI test device
>>>             - verifies transfered data
>>>
>>> Patch 8: Added ACPI IORT tables, was needed for internal project purpose, 
>>> but 
>>>      posting here for anyone looking for testing ACPI on ARM platforms.
>>>      (P.S: Linux side IORT patches are WIP)
>>>
>>> Repo:
>>> https://github.com/pmallappa/qemu/tree/upstream/smmuv3/v2
>>>
>>> To Test:
>>> $ make tests/smmuv3-test
>>> $ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 tests/smmuv3-test
>>> << expect lot of prints >>
>>>
>>> Any comments welcome..
>> As Prem was forced to stop his activity on this series, I volunteer to
>> pursue his work. Prior to starting the work, I just would like to check
>> nobody works on this already or objects.
>>
>> If not, I intend to rebase and will do my utmost to align, when sensible
>> with what was done on Xilinx vsmmuv2/intel iommu.
> 
> 
> That would be awesome! Sorry for the late reply.
no worries.
> 
> I had some comments on the PCI integration that Prem did but I'm not sure
> it matters now if you're going to go through the work. We can do a review
> of your future patches instead.

I plan to send a respin this week. As I am still getting familiar with
the code, this may be mostly a rebase on 2.9 plus some cleanups. Then I
plan to dig into more details, add missing features, maybe reuse your
table translation code if you allow me to do so, share a base class. So
I will be delighted to share about enhancements and possible reuse of
your code too.

note: at the moment I chose not to use the register API since you said
that maybe for this IP it didn't bring much added-value.

Thanks

Eric
> 
> Cheers,
> Edgar
>