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

[Edgar E. Iglesias]

On Mon, Mar 27, 2017 at 02:18:56PM +0200, Auger Eric wrote:
> 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.

Sounds great. Feel free to re-use anything from Xilinx if needed.

> 
> 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.


Due to the large amounts of registers that share implementation it
may not be the best example to showcase the Register API. But if you
feel it comes handy for some reason, go for it. I don't really mind
either way.

Thanks,
Edgar


> 
> Thanks
> 
> Eric
> > 
> > Cheers,
> > Edgar
> >