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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 5AA93C433ED for ; Wed, 7 Apr 2021 09:27:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 7EE8E61394 for ; Wed, 7 Apr 2021 09:27:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EE8E61394 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:53892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU4TQ-0005nB-JU for qemu-devel@archiver.kernel.org; Wed, 07 Apr 2021 05:27:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU4SL-0004r0-O5; Wed, 07 Apr 2021 05:26:37 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:2072) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU4SG-0004NF-Gq; Wed, 07 Apr 2021 05:26:37 -0400 Received: from DGGEML401-HUB.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4FFf9M3CDfzRYg8; Wed, 7 Apr 2021 17:24:23 +0800 (CST) Received: from dggema765-chm.china.huawei.com (10.1.198.207) by DGGEML401-HUB.china.huawei.com (10.3.17.32) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 7 Apr 2021 17:26:24 +0800 Received: from [10.174.185.210] (10.174.185.210) by dggema765-chm.china.huawei.com (10.1.198.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 7 Apr 2021 17:26:23 +0800 Subject: Re: A question about the translation granule size supported by the vSMMU To: Auger Eric , Peter Maydell , References: <4886d8d0-cca6-d4b2-4139-29ad52020f79@redhat.com> From: Kunkun Jiang Message-ID: Date: Wed, 7 Apr 2021 17:26:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <4886d8d0-cca6-d4b2-4139-29ad52020f79@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.174.185.210] X-ClientProxiedBy: dggeme711-chm.china.huawei.com (10.1.199.107) To dggema765-chm.china.huawei.com (10.1.198.207) X-CFilter-Loop: Reflected Received-SPF: pass client-ip=45.249.212.188; envelope-from=jiangkunkun@huawei.com; helo=szxga02-in.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Zenghui Yu , "wanghaibin.wang@huawei.com" , "open list:ARM SMMU" , Keqian Zhu , "open list:All patches CC here" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Eric, On 2021/4/7 3:50, Auger Eric wrote: > Hi Kunkun, > > On 3/27/21 3:24 AM, Kunkun Jiang wrote: >> Hi all, >> >> Recently, I did some tests on SMMU nested mode. Here is >> a question about the translation granule size supported by >> vSMMU. >> >> There is such a code in SMMUv3_init_regs(): >> >>>    /* 4K and 64K granule support */ >>>     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN4K, 1); >>>     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, GRAN64K, 1); >>>     s->idr[5] = FIELD_DP32(s->idr[5], IDR5, OAS, SMMU_IDR5_OAS); /* 44 >>> bits */ >> Why is the 16K granule not supported? I modified the code >> to support it and did not encounter any problems in the >> test. Although 4K and 64K minimal granules are "strongly >> recommended", I think vSMMU should still support 16K.😉 >> Are there other reasons why 16K is not supported here? > no there aren't any. The main reasons were 16KB support is optional and > supporting it increases the test matrix. Also it seems quite a few > machines I have access to do support 16KB granule. On the others I get > > "EFI stub: ERROR: This 16 KB granular kernel is not supported by your CPU". > > Nevertheless I am not opposed to support it as it seems to work without > trouble. Just need to have an extra look at implied validity checks but > there shouldn't be much. > > Thanks > > Eric Yes, you are right. In my opinion, it is necessary to check whether pSMMU supports 16K to avoid the situation I mentioned below. In SMMU nested mode, if vSMMU supports 16K and set pasid table to pSMMU, it may get errors when pSMMU does translation table walk if pSMMU doesn't support 16K (not tested). Do you think we need to add an interface to get some pSMMU info? Maybe my consideration was superfluous.😁 Thanks, Kunkun Jiang >> When in SMMU nested mode, it may get errors if pSMMU >> doesn't support 16K but vSMMU supports 16K. But we >> can get some settings of pSMMU to avoid this situation. >> I found some discussions between Eric and Linu about >> this [1], but this idea does not seem to be implemented. >> >> [1] https://lists.gnu.org/archive/html/qemu-arm/2017-09/msg00149.html >> >> Best regards, >> Kunkun Jiang >> > > .