Re: [Qemu-devel] [PATCH RFC 0/4] ARM SMMUv3 Emulation

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Mon, Jan 18, 2016 at 06:11:35AM +0000, Prem (Premachandra) Mallappa wrote:
> > Edgar has done all of the SMMU work for Xilinx, he knows it the best.
> > I'll let him comment on it.
> > 
> > For anyone interested you can see our implementation at:
> > https://github.com/Xilinx/qemu/blob/master/hw/misc/arm-smmu.c. It does
> > use the register API that we have been trying to upstream.
> > 
> Hi,
> I took a quick look at the code, The Xilinx implements mmu-500 which is a SMMU- v2.
> I am not very familiar with V2, however, the architecture and internal workings are different between v2 and v3. 
> hence there are 2 different drivers in Linux for V2 and V3, and the code I posted is for SMMU-v3.
>

Hi,

Yes, we did SMMUv2 but I think there is opportunity to reuse quite a
bit of code.

I don't mind basing the implementation from the broadcom code but
there are a few things that could be taken from our our code or at
least re-implemented.

I haven't looked at the SMMUv3 at all but I'm guessing the translation
tables are the same. We could share code between a v2 and a v3 SMMU
and possibly even some of it with the CPU models.
Our translation code has been tested with S1 only, S2 only and S1 + S2.
We've ran it with the Linux SMMU v2 driver, XEN SMMU v2 driver and
our internal testsuites. This code could be a candidate for merging with
your SMMU code as I noticed that the broadcom implementation is lacking
some of the modes.

Another thing I noticed is that it doesn't seem like you've modelled
the TBUs (these may be named differently in SMMUv3 terminology if they
even exist)? Anyway, we need these as the address-spaces on the ZynqMP
are not all the same for all TBUs.

Cheers,
Edgar