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,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 81DB3C4743C for ; Wed, 23 Jun 2021 07:23:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 624746128A for ; Wed, 23 Jun 2021 07:23:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229886AbhFWHZ0 (ORCPT ); Wed, 23 Jun 2021 03:25:26 -0400 Received: from mga02.intel.com ([134.134.136.20]:1857 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229660AbhFWHZX (ORCPT ); Wed, 23 Jun 2021 03:25:23 -0400 IronPort-SDR: YxqLphSPVDa1R8kxD3TcslnVxLgR3GQzN/4lsiGPQOOSZ4hjUQqWAEUDmwV3RLIsWdFSzSFrso KskzXLoT/fAA== X-IronPort-AV: E=McAfee;i="6200,9189,10023"; a="194350349" X-IronPort-AV: E=Sophos;i="5.83,293,1616482800"; d="scan'208";a="194350349" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2021 00:23:04 -0700 IronPort-SDR: 5p2hsF6F1g10FIA+84l+UYLpV4WLkIZZYHvLdM3kKNv95RLieT9SKgJaHWsSwrvraxNXUaRyTV 4yFCcsE/s7Ww== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,293,1616482800"; d="scan'208";a="490587560" Received: from allen-box.sh.intel.com (HELO [10.239.159.118]) ([10.239.159.118]) by fmsmga002.fm.intel.com with ESMTP; 23 Jun 2021 00:23:00 -0700 Cc: baolu.lu@linux.intel.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linuxarm@huawei.com, thunder.leizhen@huawei.com, chenxiang66@hisilicon.com, linux-doc@vger.kernel.org Subject: Re: [PATCH v14 6/6] iommu: Remove mode argument from iommu_set_dma_strict() To: Robin Murphy , John Garry , joro@8bytes.org, will@kernel.org, dwmw2@infradead.org, corbet@lwn.net References: <1624016058-189713-1-git-send-email-john.garry@huawei.com> <1624016058-189713-7-git-send-email-john.garry@huawei.com> <60bdd7c3-d73e-c005-ddf7-069bc5065bce@huawei.com> <855dd109-1449-7bc6-3d25-7ffeeeffa82a@linux.intel.com> <2330bb52-1768-5122-9378-7923034c82bd@arm.com> <5564e4b7-99af-c357-594a-1a6efe0c1464@linux.intel.com> From: Lu Baolu Message-ID: <3f8b003a-98bd-df7b-eacc-50c04e0177b1@linux.intel.com> Date: Wed, 23 Jun 2021 15:21:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 6/23/21 6:25 AM, Robin Murphy wrote: > On 2021-06-21 15:32, Lu Baolu wrote: >> Hi Robin, >> >> On 2021/6/21 19:59, Robin Murphy wrote: >>> On 2021-06-21 11:34, John Garry wrote: >>>> On 21/06/2021 11:00, Lu Baolu wrote: >>>>>> void iommu_set_dma_strict(bool force) >>>>>> { >>>>>>           if (force == true) >>>>>>          iommu_dma_strict = true; >>>>>>      else if (!(iommu_cmd_line & IOMMU_CMD_LINE_STRICT)) >>>>>>          iommu_dma_strict = true; >>>>>> } >>>>>> >>>>>> So we would use iommu_set_dma_strict(true) for a) and b), but >>>>>> iommu_set_dma_strict(false) for c). >>>>> >>>>> Yes. We need to distinguish the "must" and "nice-to-have" cases of >>>>> setting strict mode. >>>>> >>>>>> >>>>>> Then I am not sure what you want to do with the accompanying print >>>>>> for c). It was: >>>>>> "IOMMU batching is disabled due to virtualization" >>>>>> >>>>>> And now is from this series: >>>>>> "IOMMU batching disallowed due to virtualization" >>>>>> >>>>>> Using iommu_get_dma_strict(domain) is not appropriate here to know >>>>>> the current mode (so we know whether to print). >>>>>> >>>>>> Note that this change would mean that the current series would >>>>>> require non-trivial rework, which would be unfortunate so late in >>>>>> the cycle. >>>>> >>>>> This patch series looks good to me and I have added by reviewed-by. >>>>> Probably we could make another patch series to improve it so that the >>>>> kernel optimization should not override the user setting. >>>> >>>> On a personal level I would be happy with that approach, but I think >>>> it's better to not start changing things right away in a follow-up >>>> series. >>>> >>>> So how about we add this patch (which replaces 6/6 "iommu: Remove >>>> mode argument from iommu_set_dma_strict()")? >>>> >>>> Robin, any opinion? >>> >>> For me it boils down to whether there are any realistic workloads >>> where non-strict mode *would* still perform better under >>> virtualisation. The >> >> At present, we see that strict mode has better performance in the >> virtualization environment because it will make the shadow page table >> management more efficient. When the hardware supports nested >> translation, we may have to re-evaluate this since there's no need for >> a shadowing page table anymore. > > I guess I was assuming that in most cases, proper nested mode could look > distinct enough that we'd be able to treat it differently in the first > place. For instance, if it's handing guest tables directly to the > hardware, would the host have any reason to still set the "caching mode" > ID bit? For Intel VT-d, yes, simply for compatible purpose. The guest kernel may use page tables that are not compatible with the first level translation. In this case, we must roll back to shadow page table. > > Robin. Best regards, baolu