Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 12 Jan 2023 16:31:34 +0800
From:   Yan Zhao <yan.y.zhao@intel.com>
To:     Sean Christopherson <seanjc@google.com>, <kvm@vger.kernel.org>,
        <intel-gfx@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
        "Zhenyu Wang" <zhenyuw@linux.intel.com>,
        Ben Gardon <bgardon@google.com>,
        "Paolo Bonzini" <pbonzini@redhat.com>,
        <intel-gvt-dev@lists.freedesktop.org>,
        "Zhi Wang" <zhi.a.wang@intel.com>
Subject: Re: [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into
 check for 2MiB GTT entry
Message-ID: <Y7/FZpizEyIaL+Su@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.com>
References: <20221223005739.1295925-1-seanjc@google.com>
 <20221223005739.1295925-4-seanjc@google.com>
 <Y6vXTcxDNovrmeVB@yzhao56-desk.sh.intel.com>
 <Y7SaklDQD0EoIs8l@google.com>
 <Y7Y+759IN2DH5h3h@yzhao56-desk.sh.intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y7Y+759IN2DH5h3h@yzhao56-desk.sh.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B6R8NXezC8bEDu7gj07TB8c+ZtOuern151OpxogjEtIxWSuem2I8V9jZe1DF?=
 =?us-ascii?Q?L8s5w7JO6IhSRnjoAsaa9yFGPtqkeCblfFsBMElEL5tjg/mKezHCKSUBLUmw?=
 =?us-ascii?Q?ud8RclDs5K5YS60aR9EY6kk58hzdpG9ZFOwy5AVlvavGiJwwJbOYikoC7eNg?=
 =?us-ascii?Q?uoxsqoVRZcIz/8sZ0mc1rMU7UIoLmclZxVDAuffskf+bTDebiRpD+nFTrDI7?=
 =?us-ascii?Q?Xs2sGeEVi+sTBPR+Rcy5WD35fFcesZdrlNSkCY0tqrvRvOvnLitsa678pvut?=
 =?us-ascii?Q?nbPlYqE8sHxDisRkdQfS4+5rS45sdnN88+94GA4eoKvx56yU1p6oTtHG+7fv?=
 =?us-ascii?Q?hdSX5DMbUsdEC3Vip/D9otIME4QlnglgHdHZ9tfmklNigkDg7sOZTNzI1WF6?=
 =?us-ascii?Q?miuOrQdFaX5pfWI22MlehZipoVydHugAIOU9TLxkgPOaZNbFrKkJGxeu0aIF?=
 =?us-ascii?Q?MB311XbKRAe37BJ8fJErokRwRhrcErYTvmuwg+bqvDquy1VERistPSANmtaF?=
 =?us-ascii?Q?9GWa0noJFqRO7fpYeFA8x4dvCNEgyLtkugM3fm/5RbDr10v4iFw3TTbK56e3?=
 =?us-ascii?Q?qvvGcMB55yyNwdhDBFW/oBGmquXr2C/hlT7HdjzhxsMHd2uAbX2Sf1Il/kIl?=
 =?us-ascii?Q?6SGM3Hj0XnBRb8RTrhEqrgQwanmhHURaqOCCaGAd1nLe7ueyq9VhdBRaT2k2?=
 =?us-ascii?Q?3qHzda+eO8ba8DUXlkZk9ycFV/Q3WNMdcH+t1JQRa35p8UF/diUvGR24RB6T?=
 =?us-ascii?Q?LdWnqfwtm2PP20LHNJVkSVvZMm0bJsAETh95Aiigg5APInf/CPbblw2cc/Ij?=
 =?us-ascii?Q?z/AgRqsAKKD5AnE7fqWM0+jeADmKnBnzlr8iltRgJBXB3B0y+HOoX8jHMMUi?=
 =?us-ascii?Q?5jFnH4JzLHmpGhdf2nk2NgVoTqJVePHihe9+XHZQV/E85q9tH4ST8cYgFsuh?=
 =?us-ascii?Q?TOE6crgg4ucGG3xbrq/c2AdyY9mjvDXvBQAC8fi56WA6TG+VYzyXpVmjdmCu?=
 =?us-ascii?Q?XjTWRxkeReFQcpHfRDHrQRa4HLENV+GPGWPQMH2D3rc/80ms9apdOinz7x8b?=
 =?us-ascii?Q?ayzDSVMszHjJf5DE49wn8pqZWavOigaLq8bLekoOqqSCfBkSZCuFVCimCueT?=
 =?us-ascii?Q?QrUCPhECt7hD/IzAyRiyLTquLcZ/UHVsgjxGJJua+fOcG414KQttxky+j6Z9?=
 =?us-ascii?Q?Mkf3ysBT8vopXtW6030/mWXhapttHTISZ+4ft0UnGtuaHkpdXSCXsfguqUZg?=
 =?us-ascii?Q?nBo9Syg5LjgkIddj+KzK0xWj2U8gjZtm4YygL2oTQC+i3VfuHG4wFUU+BZfI?=
 =?us-ascii?Q?zP2QXkFZxfEffzRjVzPt/efM/uW2Ih2Q6/OkD9BRFt/HAxpJz/4FZ9BV/n+n?=
 =?us-ascii?Q?vTUPxmKT4QtRxNC3BnxTFVeqICsK8SkTX3ey/kT32LpuYC+fNE1Jx8tcrkzs?=
 =?us-ascii?Q?oBL/0NSCHkjm485uT0xkytGInZwvdKle5i9AwM2341gex39ksJQUVkiMP8R5?=
 =?us-ascii?Q?4Co3Z1dzX0ZUUIRYNqtog5xC64VWltcbGOX/qTDRLDN1HvNcY1DyC1bnFYnx?=
 =?us-ascii?Q?M0fGUUsB5esURyQe2h7LPgpMb9JhPGUIRdArhqf3?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 432ede82-7faf-4544-5852-08daf47ab265
X-MS-Exchange-CrossTenant-AuthSource: DS7PR11MB5966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2023 08:55:04.3927
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TpmUvJA2hs8vbydJ4JJEbgb7fcrJQAyRd6xDEGzdqiOt0bmhyCsW/Pk6TLVvH4yXLwlyyENNDn0CG9hz78Mzbg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5120
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > > > Note, KVM may also restrict the mapping size for reasons that aren't
> > > > relevant to KVMGT, e.g. for KVM's iTLB multi-hit workaround or if the gfn
> > > Will iTLB multi-hit affect DMA?
> > 
> > I highly doubt it, I can't imagine an IOMMU would have a dedicated instruction
> > TLB :-)
> I can double check it with IOMMU hardware experts.
> But if DMA would tamper instruction TLB, it should have been reported
> as an issue with normal VFIO pass-through?

hi Sean,
This is the feedback:

- CPU Instruction TLB is only filled when CPU fetches an instruction.
- IOMMU uses IOTLB to cache IOVA translation.
  A remapping hardware may implement multiple IOTLBs, and some of these may
  be for special purposes, e.g., only for instruction fetches.
  There is no way for software to be aware that multiple
  translations for smaller pages have been used for a large page. If software
  modifies the paging structures so that the page size used for a 4-KByte range
  of input-addresses changes, the IOTLBs may subsequently contain multiple
  translations for the address range (one for each page size).
  A reference to a input-address in the address range may use any of these
  translations. Which translation is used may vary from one execution to
  another, and the choice may be implementation-specific.
- Theres no similar bug related to DMA requests for instruction fetch hitting
  multiple IOTLB entries reported in IOMMU side.
  The X bit in IOMMU paging structure is to be removed in future and is
  currently always unset.

Thanks
Yan