From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3AEE82FE567 for ; Thu, 29 Jan 2026 14:36:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769697406; cv=none; b=UDZi9me2BvVmaM3FUcKumGtTig3wmeNxA87NEdzMJyQ38DikIBBG+hUQk/88ZAZNQGlfpGv9vt2a9OTsHsUq2byoGV4RZ9rOoh2RvMJRlhKi8qxQOm6Be+67aN6N7hObAoBEJYYbuDL7L8r6bgOvvWCoGSKaqMtKP7d2aiT0MMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769697406; c=relaxed/simple; bh=znwZloF/bqh5zsvZiN44nSWQB16aALxNizfmVX+WlRw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=DfQMGyLO5nupFMljeocqKB0IRC/RqDzuUrWUsd3H2cjzmXZ2x12CHV1Hy1tYZpdJIBgCwGNYJOnESh/rI2xj0pUMHTfDTla4MrKAsiMhHuOCXXJ11csFruHkcJxslSbcg7d/BKDMf1KOCWv3bcBokQikGz5BTUIGmtWDOTZFSg4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=02+0m23J; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="02+0m23J" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-34c5d203988so1868870a91.3 for ; Thu, 29 Jan 2026 06:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769697403; x=1770302203; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Fc8ELM/gTsPjpCHlht3R3Sj8sQv9T3iDgJmyY1+bv10=; b=02+0m23JQKEJTkyNwefQedtPAH4wx78VBGXTZBbL9HqFoF1xbClZwV/PxJ+vGTzwIw 1n4e9XHXlVs0QDKo5nlord1ir4r6lUQOa7h0gKNDlSetoVwopoyxogrnUxcuCxPWR/mD wP1H0IQmWwnv9WB6J3FolwIjAJV9SDLlppOFakqTfEpdup5Vxs4ZrQTY3NDuV7tFlckt Gv4UGA/9Y4dL/7mH8LSc6uOY1cAuxFnlS2ZMIAu5w64FigkIyNZVunxtbix54WC6E9pn Jvj+71jwq36KpsD9tAHsXwsxmVguu7yJYSNu2PhIQJvjmxA1DwKgCYSSChKxaRN4EuL4 3YAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769697403; x=1770302203; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Fc8ELM/gTsPjpCHlht3R3Sj8sQv9T3iDgJmyY1+bv10=; b=IipNCsxLi8SMdBKKqIA9aT50EpFWaMr7QGWJ8zfLktWxChMygFRznytix5JJ6vmF8O IS4xfleu7YqNM9J2n1hs+zyESTr8fwplo8EUYbOzTfi5IS3ZNn869PcFCg8uQAFqfpo/ Eszvijp+G/Tq7GmN82//fZlZDCyRIxoLMEUbR/AD+xT5Cj9IZ9gTy8JiMcp8ESVGizcl bPUEYnZWWxEy/a+HkV017aypBJDMvCcA7LEkgmXJsEh14jr8/YqteC8hY679p9TNppiC FAx3Y9UTo9QaLyW13MiyOw1voxKQl8ol8+Fbz4FhWJZOA/cSACSorl4UbTIrC8tM6t7p mseA== X-Forwarded-Encrypted: i=1; AJvYcCV+YADNokd78uPpEdvdlAmftWc0DHtGs0TrsQoVmzCt82OjA2iiNxCLHluVsiLy3gpKdysUbjhenEmYFy8=@vger.kernel.org X-Gm-Message-State: AOJu0YyjkhNJ+SP6nMdV1fNnJClbE6k+Dn/ILUvKqki84msL6jfrvWca KL4RwFB1luwt20wwYxRZwvlJVX0iERmzVbIB9XLJYmQpHOIqLvebnDxsr6nFpEmMZdh2TIhPrlq qQcrdng== X-Received: from pjbmp8.prod.google.com ([2002:a17:90b:1908:b0:353:2f4:eaf9]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:3901:b0:353:e91:9b2f with SMTP id 98e67ed59e1d1-353fedcc422mr8402350a91.37.1769697402792; Thu, 29 Jan 2026 06:36:42 -0800 (PST) Date: Thu, 29 Jan 2026 06:36:41 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260106102136.25108-1-yan.y.zhao@intel.com> <2906b4d3b789985917a063d095c4063ee6ab7b72.camel@intel.com> <3ef110f63cbbc65d6d4cbf737b26c09cb7b44e7c.camel@intel.com> Message-ID: Subject: Re: [PATCH v3 11/24] KVM: x86/mmu: Introduce kvm_split_cross_boundary_leafs() From: Sean Christopherson To: Yan Zhao Cc: Kai Huang , Fan Du , "kvm@vger.kernel.org" , Xiaoyao Li , Dave Hansen , "thomas.lendacky@amd.com" , "tabba@google.com" , "vbabka@suse.cz" , "david@kernel.org" , "michael.roth@amd.com" , "linux-kernel@vger.kernel.org" , Chao P Peng , "pbonzini@redhat.com" , "ackerleytng@google.com" , "kas@kernel.org" , "binbin.wu@linux.intel.com" , Ira Weiny , "nik.borisov@suse.com" , "francescolavra.fl@gmail.com" , Isaku Yamahata , "sagis@google.com" , Chao Gao , Rick P Edgecombe , Jun Miao , Vishal Annapurve , "jgross@suse.com" , "pgonda@google.com" , "x86@kernel.org" Content-Type: text/plain; charset="us-ascii" On Mon, Jan 19, 2026, Yan Zhao wrote: > On Mon, Jan 19, 2026 at 07:06:01PM +0800, Yan Zhao wrote: > > On Mon, Jan 19, 2026 at 06:40:50PM +0800, Huang, Kai wrote: > > > Similar handling to 'end'. An additional thing is if one to-be-split- > > > range calculated from 'start' overlaps one calculated from 'end', the > > > split is only needed once. > > > > > > Wouldn't this work? > > It can work. But I don't think the calculations are necessary if the length > > of [start, end) is less than 1G or 2MB. > > > > e.g., if both start and end are just 4KB-aligned, of a length 8KB, the current > > implementation can invoke a single tdp_mmu_split_huge_pages_root() to split > > a 1GB mapping to 4KB directly. Why bother splitting twice for start or end? > I think I get your point now. > It's a good idea if introducing only_cross_boundary is undesirable. > > So, the remaining question (as I asked at the bottom of [1]) is whether we could > create a specific function for this split use case, rather than reusing > tdp_mmu_split_huge_pages_root() which allocates pages outside of mmu_lock. Belatedly, yes. What I want to avoid is modifying core MMU functionality to add edge-case handling for TDX. Inevitably, TDX will require invasive changes, but in this case they're completely unjustified. FWIW, if __for_each_tdp_mmu_root_yield_safe() were visible outside of tdp_mmu.c, all of the x86 code guarded by CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT[*] could live in tdx.c. Hmm, actually, looking at that again, it's totally doable to bury the majority of the logic in tdx.c, the TDP MMU just needs to expose an API to split hugepages in mirror roots. Which is effectively what tdx_handle_mismatched_accept() needs as well, since there can only be one mirror root in practice. Oof, and kvm_tdp_mmu_split_huge_pages() used by tdx_handle_mismatched_accept() is wrong; it operates on the "normal" root, not the mirror root. Let me respond to those patches. [*] https://lore.kernel.org/all/20260129011517.3545883-45-seanjc@google.com > This > way, we don't need to introduce a spinlock to protect the page enqueuing/ > dequeueing of the per-VM external cache (see prealloc_split_cache_lock in patch > 20 [2]). > > Then we would disallow mirror_root for tdp_mmu_split_huge_pages_root(), which is > currently called for dirty page tracking in upstream code. Would this be > acceptable for TDX migration? Honestly, I have no idea. That's so far in the future. > [1] https://lore.kernel.org/all/aW2Iwpuwoyod8eQc@yzhao56-desk.sh.intel.com/ > [2] https://lore.kernel.org/all/20260106102345.25261-1-yan.y.zhao@intel.com/