From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.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 EF0633D9DC1 for ; Fri, 17 Jul 2026 13:09:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784293749; cv=none; b=mNKA+IULtYSNZAXZ/AIlGrHLblrtchtNN5mdE76hz/wqWJ75z8Wqz9KNc25JH+4Djy2kfg8DUGHzPcgZPEY8/PNv3P8Ab23XFgoYuZFbrq/tttMjlTV+3/4rUWwzduNN003F4GQj87TaXtweW48xGx6kYnFT9IV4RzCNeYf5B0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784293749; c=relaxed/simple; bh=kHv+nS4iJ3RfuYjzkETMJs9ejwONqp1/BT4HoVMehqc=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=qTHbnLtSrNGOKmryLJFbq2k3BdDpdfLPiXOyFuTkvRBl7Ts4TCeE9bsURS12JTsm/AXOzWI/jHC1wYvU6KpPXoPIjbkFPphoOz+sKW8k7JKTWMaDgZTGlgWgMhdmWxr0z5E263cxW8uyHtFrSu7j15XNVeg9ND5fdU4/UE6xsao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=eYSR5itS; arc=none smtp.client-ip=209.85.221.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--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eYSR5itS" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-473941177b0so6421411f8f.1 for ; Fri, 17 Jul 2026 06:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784293745; x=1784898545; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:from:to:cc:subject:date:message-id :reply-to:content-type; bh=S08p5kQZpXbD9KawmMzLPf/sCiQ1d3STxcaWnwOPLP0=; b=eYSR5itS/p2AoNOYCSiLk9nQUrWDUdkU9H70/vCbbgCervWVBVB081TP2e3puBnyy+ B/RsW8zRqf+Sv/a7hTRtImw1fK6fduaP9vsm04GSxd0G9SvdNQsk6lXZ9/HwtvBcK7Gi D963GmY8CEEXbM2HO7yGWPqbvNfKBF0Cs1nyI501dAJCmZNGwUFLMtbgNxNnjARlm5U0 7P0TogPou4x1tJvI+8wBrT5FUoSB6SfUEg4u61oSUpAQdNMsGKgtty1GGKkXCto2GBey KX6Bo1Y/l6h9TcqVuQKUVvjhGNxUcyU7hnxfdDzDSCCmn6uumzm2O0sUYi1F4PQPdDnu GxVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784293745; x=1784898545; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=S08p5kQZpXbD9KawmMzLPf/sCiQ1d3STxcaWnwOPLP0=; b=KRp3REN52dbMm+4fpir+N1n86ArRWMi2qXRRoOwDLU3G2U90vtaZj6Wm2zWI3SXpzB nSmiUzbr0vCMJGNa7OAZJZpBMZbXvY3afusd/WmLmQcW7r8DRleZF2Byjuyqx5w0D9C7 S6n914M2BEn+9fBmkG4ukUBIqI8PljNRvZX3SYkwx0ppWOGc/dnkfX+GJDUCwIOdknM4 022fb7a53OZTgHkz+D6Vh/oZx1Sljpl0CVEw5rYr6+yR6Or3eFhhCna39i8l4M73LHbW zlkHaK4j31xrI0fBLvmr0sloIFzcd+inHEVEQdUsaVJBJZ1VnmLyQ1z49y2kY2ZrmeVW Wu1w== X-Gm-Message-State: AOJu0YxDqNAbxk7LRuEe3S+GnTtW4UwozFSvdChrYW5cBLIIsQ+ztHHu a5o5IVh/32HT+Tt/086TUymtEkVdPeW+pXo3+8cOyJVD4OpTh5N7wRXl8gfRc61Dr4USVEZDC/6 jP3+79H5YO9sYLLy5Cl5dtBZ4buICosm+nxYz/KZasztC1V4sp4rAhMGYZtWFLWQjx5fcYHlaVh v5DEd/d3Ez+JprNNU9ZDKjQVAPxaJ7ZuaK4GKES0YAKG8+rwaLLku3Z7k= X-Received: from wmco24.prod.google.com ([2002:a05:600c:a318:b0:493:c42c:7e97]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:190d:b0:495:3da0:3f52 with SMTP id 5b1f17b1804b1-4954a40e0efmr29494085e9.19.1784293744623; Fri, 17 Jul 2026 06:09:04 -0700 (PDT) Date: Fri, 17 Jul 2026 13:08:58 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.229.g6434b31f56-goog Message-ID: <20260717130901.2239134-1-smostafa@google.com> Subject: [RFC PATCH 0/2] KVM: arm64: Support BBM level 3 From: Mostafa Saleh To: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: maz@kernel.org, oupton@kernel.org, seiden@linux.ibm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, vdonnefort@google.com, tabba@google.com, Mostafa Saleh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This patch series adds support for BBM level 3 to KVM pgtable, it depends on [1] Motivation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have been looking into this for the context of: - Page table sharing between the host CPU stage-2 and the SMMUv3 for protected KVM. - Use the pagtable code to populate SMMUv3 stage-2 shadowed page table [2] However, BBM level 3 is still useful for CPU only operations as it avoids intermediately breaking translation. Design =3D=3D=3D=3D=3D=3D Some of the conditions that BBM level 3 will be useful in (RWHZWS): 1) A change to a PTE memory type, shareability, cacheability or OA 2) Changing from block to table 3) Changing from table to block At the moment in the hyp page table code: - For #1) stage2_map_walker_try_leaf(): Replaces a leaf with another one which does not match the same OA/perms/attrs. - For #2) Switch block to table is used from: - kvm_pgtable_stage2_split(): Explicitly splitting a block (used for dirty logging), where a block is replaced by a table with the same attributes. - stage2_map_walk_leaf(): Updating a mapping that is partially part of an existing block. - #3) Does not exist in the code at the moment as coalescing is not supported. The first patch is a preparation to be able to clean up the old pte for BBML3, the second patch adds the main logic. Initially, I encapsulated the full logic of BBM in one function, which was not readable, due to different ordering and dealing with CMO, TLBI. Instead, I kept the logic into 2 functions, where BBML3 is added in the make step. One interesting case, as BBML3 will update the PTE atomically, it can only know it raced with another core at the point of the cmpxchg failing, unlike the SW implementation which locks the PTE first. And as we must issue CMOs to the new mapped page before the update, that means with BBML3 racing cores will issue redundant CMOs, to improve this: - We only use BBML3 if the old PTE was live - To reduce the window of the race an early check is added before the CMO to exit early, but that does not eliminate the race. Testing =3D=3D=3D=3D=3D=3D=3D This was tested: - C1-Pro cores, unfortunately the version I have does not run upstream, I backported the patches to Android kernel (6.18). - mainline(7.2-rc3) kernel on a Qualcomm X1 with a hacked cpufeature as it does not support BBM, I did not see conflict aborts or TLB corruption. I tested with VHE and protected (hvhe) modes, running VMs (and protected), and running some selftests, that might exercise and stress this path tools/testing/selftests/kvm: - demand_paging_test - memslot_perf_test - memslot_modification_stress_test - dirty_log_test Future work =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some other changes that would be useful for the SMMUv3: - Eagerly install table on block split, we can now replace a block with a fully populated table atomically when we unmap a partial part of the block. There is more to support page table sharing (such as dealing with TLB invalidation, coherency=E2=80=A6), I submitted a talk to LPC to discuss this further. [1] https://lore.kernel.org/linux-arm-kernel/20260715053408.1950475-1-linu.= cherian@arm.com/ [2] https://lore.kernel.org/linux-iommu/20260715115906.2664882-1-smostafa@g= oogle.com/ Mostafa Saleh (2): KVM: arm64: Add stage2_clean_old_pte() KVM: arm64: Support BBM level 3 arch/arm64/kvm/hyp/pgtable.c | 118 ++++++++++++++++++++++++----------- 1 file changed, 82 insertions(+), 36 deletions(-) --=20 2.55.0.229.g6434b31f56-goog