From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL9kw-0001ms-0d for qemu-devel@nongnu.org; Mon, 18 Jan 2016 08:22:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL9ks-0007NS-PX for qemu-devel@nongnu.org; Mon, 18 Jan 2016 08:22:01 -0500 Received: from mail-pa0-x243.google.com ([2607:f8b0:400e:c03::243]:35988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL9ks-0007NN-JF for qemu-devel@nongnu.org; Mon, 18 Jan 2016 08:21:58 -0500 Received: by mail-pa0-x243.google.com with SMTP id a20so27539673pag.3 for ; Mon, 18 Jan 2016 05:21:57 -0800 (PST) Date: Mon, 18 Jan 2016 14:21:53 +0100 From: "Edgar E. Iglesias" Message-ID: <20160118132153.GN29396@toto> References: <1452521812-5664-1-git-send-email-pmallapp@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC 0/4] ARM SMMUv3 Emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Prem (Premachandra) Mallappa" Cc: Peter Maydell , Peter Crosthwaite , QEMU Developers , Alistair Francis 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