From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6A41C43461 for ; Wed, 16 Sep 2020 21:13:30 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 36478206DB for ; Wed, 16 Sep 2020 21:13:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="oN4JBAnR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36478206DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kIejj-0005zD-Uu; Wed, 16 Sep 2020 21:13:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kIejj-0005z8-IU for xen-devel@lists.xenproject.org; Wed, 16 Sep 2020 21:13:07 +0000 X-Inumbo-ID: 13d7c8dd-6b96-48bd-a413-5e8a6aa9d159 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 13d7c8dd-6b96-48bd-a413-5e8a6aa9d159; Wed, 16 Sep 2020 21:13:06 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id e16so8346070wrm.2 for ; Wed, 16 Sep 2020 14:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xEeXcGAjXvR8gsIv0zarjPW/Tba4FnvziiCMbowz46I=; b=oN4JBAnRA50nRpK9CGaFIbEdbBVyI34slNVRm7glYOWFhmBb2suF0Lemim4JRRTxGu SSXQVkxQFoylRBesk6IGvce2NLQ8OkYy9kww/dcTaOk0+4beF2x/ELd5mGDQLY961FvM lbNHvTL4KmPnIhUcI0xuoOOAjOZvWj2cpuzxHY4f9SPKIIxR/5NsTE/l2sCa74bjC4rn Ot4kFnm66sVQA4cstyAsHiQ3SBok2VrvqsmMIkoL1Zqugx+/PnED1oLI75H/XtpkMl6X 2Q+vt9UFiZFTHDL1vVd05oLhkD90gBzXmNBoNRJRh+TyOX9mm8AtHJrLV7peiL8wYlef frGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xEeXcGAjXvR8gsIv0zarjPW/Tba4FnvziiCMbowz46I=; b=S9PoATX9qqlBf9VhF/MFt4WuYvo1lbBZ6A/qNjlbHvIruhfXaMgzv0hBpAngtoi7Gj /GmIqV4joxe0N0cUDgVehTCmbje9r9/ktZAr1g3BgKOPIl7uOOLRF/GeOYeAyXL+THBY 2KqniJB6QR6NCFG2kR79YUzCoIIfV15CV9DVeXEJUeNJJYLrfNeJ5KG5yfQ2V9S0OV0j 5SmFmLzDGEp8jtcNMxFyQJ6l5tYJkSzH8ddCm2vWqKS9U/hRsWvaSdrAvssdXbMIMDzJ JSdD2YciEC7bYmS6Ehm2eQX//4WwU5ySe1vGyNUMcoNbf4GExe73ggBiz//DTr+ysz+W X+QQ== X-Gm-Message-State: AOAM533MRxrEfkwNY/L7DLXAKAN2q4l6ONgB6vf3hENbsaRtHHqqf8x+ lDvQjgbug7hr0gHKJxChD4TA/cwhipp+SJX8TJM= X-Google-Smtp-Source: ABdhPJyN5kWFaDeNv7ygIrxfnUoF+yyvLtqFz6TZqZJmtASX2I8qA6grT2db+ayZPU+Cjdd7DVqoXPM0cID79E4skEw= X-Received: by 2002:adf:f548:: with SMTP id j8mr29749111wrp.114.1600290785533; Wed, 16 Sep 2020 14:13:05 -0700 (PDT) MIME-Version: 1.0 References: <1600112240-31726-1-git-send-email-olekstysh@gmail.com> <6c16083d-27c2-b325-99eb-1e8ff326ac03@xen.org> In-Reply-To: <6c16083d-27c2-b325-99eb-1e8ff326ac03@xen.org> From: Oleksandr Tyshchenko Date: Thu, 17 Sep 2020 00:12:54 +0300 Message-ID: Subject: Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported To: Julien Grall Cc: xen-devel , Oleksandr Tyshchenko , Andrew Cooper , George Dunlap , Ian Jackson , Jan Beulich , Stefano Stabellini , Wei Liu , Volodymyr Babchuk , Paul Durrant Content-Type: multipart/alternative; boundary="000000000000cf22ef05af74bbc9" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --000000000000cf22ef05af74bbc9 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 16, 2020 at 8:02 PM Julien Grall wrote: > Hi Oleksandr, > Hi Julien [sorry for the possible format issues] > > On 14/09/2020 20:37, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > > > And remove dependencies on CONFIG_EXPERT. > > In order to help to make the decision, can you provide the following > information: > - Is it functionally complete? > I think, yes. At least I am not aware of any remaining issues which prevent us from using Xen driver normally these days. There was one important issue related to the known R-Car Gen3 IPMMU-VMSA limitation to handle maximum 40-bit IPA only (so 4-level translation table is not supported) and this issue didn't allow us to have the Xen driver *completely* functional. Hopefully, we have already found a proper way to handle this in Xen on Arm [1]: > - Can it work on all known platforms with IPMMU VMSA? > I don't think Xen driver will work on all known platforms with the IPMMU-VMSA. Xen driver is supposed to be used with newest R-Car Gen3 SoC revisions only (H3 ES3.0, M3-W+, etc.) which IPMMU H/W supports stage 2 translation table format (to be able to share the P2M with the CPU). On older SoC revisions it won't work (driver performs a special check at the initialization time to see whether the P2M sharing is supported in current SoC revision). Being honest, the R-Car Gen3 family is not limited by these 3 SoCs (H3, M3-W+, M3N) the driver is looking for. There are other SoCs: E3, D3, V3H, V3M, etc, which are quite new and likely have a *proper* IPMMU H/W to be used in Xen. But, I don't have a possibility to check them in order to be 100% sure and extend a number of supported SoCs in the driver. > - Is there any plan to smoke (manually or automatically) test the > driver? > Yes, there is a plan to perform manual tests. Actually, this is what we usually do in the context of our development. After all, device passthrough is one of the important features and keeping this driver in a functional state is our target. [1] https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02967.html -- Regards, Oleksandr Tyshchenko --000000000000cf22ef05af74bbc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 16, 2020 at 8:02 PM Julie= n Grall <julien@xen.org> wrote:=
Hi Oleksandr,

Hi Julien

[sorr= y for the possible format issues]
=C2=A0

On 14/09/2020 20:37, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> And remove dependencies on CONFIG_EXPERT.

In order to help to make the decision, can you provide the following
information:
=C2=A0 =C2=A0 - Is it functionally complete?
=C2=A0
I think, yes. At least I am not aware of any remaining issues which= prevent us from using Xen driver normally these days.
There was one imp= ortant issue related to the known R-Car Gen3 IPMMU-VMSA limitation to handl= e maximum 40-bit IPA only (so 4-level translation table is not supported) a= nd
this issue didn't allow us to have the Xen driver *completely* fu= nctional. Hopefully, we have already found a proper way to handle this in X= en on Arm [1]:
=C2=A0
=C2=A0 =C2=A0 - Can it work on all known platforms with IPMMU VMSA?
=C2=A0
I don't think Xen driver will work on al= l known platforms with the IPMMU-VMSA.
Xen driver is supposed to be used= with newest R-Car Gen3 SoC revisions only (H3 ES3.0, M3-W+, etc.) which IP= MMU H/W supports stage 2 translation
table format (to be able to share t= he P2M with the CPU). On older SoC revisions it won't work (driver perf= orms a special check at the initialization time to see whether
th= e P2M sharing is supported in current SoC revision). Being honest, the R-Ca= r Gen3 family is not limited by these 3 SoCs (H3, M3-W+, M3N) the driver is= looking for.
There are other SoCs: E3, D3, V3H, V3M, etc, which = are quite new and likely have a *proper* IPMMU H/W to be used in Xen. But, = I don't have a possibility to check
them in order to be 100% = sure and extend a number of supported SoCs in the driver.
=C2= =A0
=C2=A0 =C2=A0 - Is there any plan to smoke (manually or automatically) test= the driver?
=C2=A0
Yes, there is a plan to = perform manual tests. Actually, this is what we usually do in the context o= f our development.
After all, device passthrough is one of the im= portant features and keeping this driver in a functional state is our targe= t.

[1]=C2=A0=C2=A0https://lists.xenproject.org/archives/htm= l/xen-devel/2019-09/msg02967.html

--
<= div>
Regards,

Oleksandr Tyshchenko
--000000000000cf22ef05af74bbc9--