From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B0E835AC0C for ; Tue, 2 Jun 2026 14:21:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780410063; cv=none; b=Xon/FsATXtv9/GGsGVZQtDZbJDmKBYnYo51ti1Hjhfz7FBFdiiP+clCIlsSgY/dM6rmTAmqVvvMZfNKK2Xdg/2t12cpuK/FaKMkTPhiIOPEMSXvTiROxp4m9rfbzEU4xT+hUyy8oD4yTYQmqA0ToOODtLkcHvuS6HslAATWtd+8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780410063; c=relaxed/simple; bh=+W0rrURTIZCgH+yOdPQlNjDHpWvV+3WBIFW2/XMLMNo=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=mOqgGzx4h+as4zZf5AOgLz6cIga/yyhgZA9Oe39ULRVhb39QCJG3ZA/F8khCWvk4MVGNGwuDNB1h1axYAVSMGESuijExE1Tb81a9vEFvSturA1/4aAvsHNaR7bRS6/RL607NTLul6HUTNN3KVAkD43OVWNnkJaqxEe7xhFHn1Tg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BUeHV4ld; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=sc2N/HcY; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BUeHV4ld"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="sc2N/HcY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780410061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gNgFgrpf7w/FMs0bq28uFQIumMwYrw0jgR/RkY8a7d0=; b=BUeHV4ld/XB/j+RmQEc3ws+y4DsXra7UMKB3JmdcllLCAM7MIUuzqxjrhr5qOFzox4xMT2 ylgXYcsbwZRhsRalDu6MwgWDSjcXaQWlHFTWuFqNtluqpiuq9J/vmYcjSXmwpLu4wCJSeq +yIGJEQ71TQhr396l/Ema3e91hHzENs= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-650-Yg0qGS3bNK-ddgNXarQB0A-1; Tue, 02 Jun 2026 10:21:00 -0400 X-MC-Unique: Yg0qGS3bNK-ddgNXarQB0A-1 X-Mimecast-MFC-AGG-ID: Yg0qGS3bNK-ddgNXarQB0A_1780410060 Received: by mail-ua1-f72.google.com with SMTP id a1e0cc1a2514c-96396658728so1175141241.1 for ; Tue, 02 Jun 2026 07:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780410060; x=1781014860; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=gNgFgrpf7w/FMs0bq28uFQIumMwYrw0jgR/RkY8a7d0=; b=sc2N/HcYWWPSUVPXL7hpKfN7c188MjS9Oi3FIPWDGYV3r6S5C5opmypFBuUdMz8E0k 7mvjLCT0u74VeHCHyGMzitYEYt6rHqyYqjhPaZ6/oaVjq25Uan2M/bY1LALbHdGKriZY lbtYG+hmmgMaGIAedU4NvpOF7AkXdYSNVsUYCei7xnR6IG6B/K+V2PnBQwNiwJRn7YE4 N+Eg8z1w19iOCtoZ+wA50zvQ4n7Dh+7Z2XD++O6Cf5C5dH924KgTjxxkfmgwK6FwR9qh t3uE8QIPMaMUC2P91AMD+iQXaqe7UYImWtF43piJEtRcqgD76dwk8GoYrhdcy0mXI9G8 uIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780410060; x=1781014860; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gNgFgrpf7w/FMs0bq28uFQIumMwYrw0jgR/RkY8a7d0=; b=gTEJ2WSnpJ8mXwtqQoXIiqbK/9dxMCEZCykhQnnRICsw41XAb8Spz9C8rtJ8Rr0hY+ 7Jmrd7cc/pJ3yDd4skWr+1jORsOKETjBSF+1lMr4j6xUJSY9zBjXcwvnsjkHibmRgfAt TckK8TrmSl0HzOipxB1j6J8c1nmA0jUYOOkAO9EcdV4dzXHZPLh6KYbA+QWc1xK8uDlF vNSjR7sbiShlcwCUyB+ddSTYdU8S2gVFW/syGbphAlP0NtWtK8RzngFQuMdb5xdZe/FI I+ozS8qTbDZjvOTHd1alZCqZpWdRRATghldZusbQTNemhdfby+sxyg+K+jYlh3YzpdUS MVXg== X-Forwarded-Encrypted: i=1; AFNElJ8oPL/09AxgEDxb8v1u/pa7OQWhd1bPu49b6lIuzs77MYIntw0CPO52Z6JoF31e/YegDp70YwSIMYLFdGU=@vger.kernel.org X-Gm-Message-State: AOJu0YzAoKGsd3IyF1+gYWDzxzrehyb9OqYOhdTT32oKx/E6zaSnIpZn Gj7WDT83n8MGPJbzXMJv6wV/14XDPoJE7Y5KIzBBfBvEIXGjTmyPzTqJhO0ETWkx/EW9Ll+UOOr Qy4+0coV5KTaiu3LwsJN6byvNIPBIBLLbNuyc3lVmTRzPlmJ8YsBG9XqDVEkjh+96GpkAALMemQ == X-Gm-Gg: Acq92OGXy57qBETGvdBOIyAmkvJugHfhqJuyR8QrlahKFEO+YY9LlurPB53N+3962BI Kzyn6zNz9CVBlfzAZOw2IDalcPn1g0JOgGoL0h66bgc4Pqzr0CAdj0L7XbJHf5VIUBXb6Wqo4tV HS4tucBXvwsVLciIy3pXZMU+z4TOgyO1rOF/QIB2v/Sml6ahswlk00/S5G5qAsoPiIrWieELZqi vb3nrVbXsHgM88bxR1JlvzakohfTwJUItmTX3YiXehIZNuM+yCXNFt21svwl5Om51uQEACkF+4e 6Uv8cd1mW7uorMSruI3XC7VDjF507Ycpf4PsrwgVguyRiGEpyHCc9KN3SbmIP+5azbu1mmAQth9 zYBoiQg5hVFoayNVT2FlE5fOk7WrEjbnGGsNXSh8= X-Received: by 2002:a05:6102:640f:b0:6cf:37fe:2cb with SMTP id ada2fe7eead31-6cf37fe145dmr3576254137.27.1780410059854; Tue, 02 Jun 2026 07:20:59 -0700 (PDT) X-Received: by 2002:a05:6102:640f:b0:6cf:37fe:2cb with SMTP id ada2fe7eead31-6cf37fe145dmr3576204137.27.1780410059317; Tue, 02 Jun 2026 07:20:59 -0700 (PDT) Received: from intellaptop.lan ([2607:fea8:fc01:88aa:f1de:f35:7935:804f]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ccea064f97sm119970196d6.13.2026.06.02.07.20.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 07:20:58 -0700 (PDT) Message-ID: <8892ec32671534e51168655fbbcce9f4340d29b2.camel@redhat.com> Subject: Re: [PATCH 04/28] KVM: x86/mmu: shuffle high bits of SPTEs in preparation for MBEC From: mlevitsk@redhat.com To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: d.riley@proxmox.com, jon@nutanix.com Date: Tue, 02 Jun 2026 10:20:57 -0400 In-Reply-To: <20260505195226.563317-5-pbonzini@redhat.com> References: <20260505195226.563317-1-pbonzini@redhat.com> <20260505195226.563317-5-pbonzini@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.4 (3.52.4-2.fc40) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-05-05 at 21:52 +0200, Paolo Bonzini wrote: > Access tracking will need to save bit 10 when MBEC is enabled. > Right now it is simply shifting the R and X bits into bits 54 and 56, > but bit 10 would not fit with the same scheme.=C2=A0 Reorganize the > high bits so that access tracking will use bits 52, 54 and 62. > As a side effect, the free bits are compacted slightly, with > 56-59 still unused. First of all thanks for documenting this black magic! Minor nitpick: There is a slight inconsistency between the commit message, which says that= bit 62=C2=A0 will be used, and the comment below, which states that=C2=A0 bit 62 is unused=C2=A0 (although in following patches this comment is updat= ed). Also, although I'm not entirely sure this is worth mentioning that bit 62= =20 just happens to be 10 bits away from bit 52, so that we can still just copy the permission bits from EPT's SPTE as a sin= gle block, even though between bits 52,53,54 and bit 63, there are other bits which KVM uses for other purposes. >=20 > Tested-by: David Riley > Signed-off-by: Paolo Bonzini > --- > =C2=A0arch/x86/kvm/mmu/spte.h | 20 +++++++++++++++----- > =C2=A01 file changed, 15 insertions(+), 5 deletions(-) >=20 > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h > index 4283cea3e66c..317b9cd1537c 100644 > --- a/arch/x86/kvm/mmu/spte.h > +++ b/arch/x86/kvm/mmu/spte.h > @@ -17,10 +17,20 @@ > =C2=A0 */ > =C2=A0#define SPTE_MMU_PRESENT_MASK BIT_ULL(11) > =C2=A0 > +/* > + * The ignored high bits are allocated as follows: > + * - bits 52, 54: saved X-R bits for access tracking when EPT does not h= ave A/D > + * - bits 53 (EPT only): host writable > + * - bits 55 (EPT only): MMU-writable > + * - bits 56-59: unused > + * - bits 60-61: type of A/D tracking > + * - bits 62: unused > + */ > + > =C2=A0/* > =C2=A0 * TDP SPTES (more specifically, EPT SPTEs) may not have A/D bits, = and may also > =C2=A0 * be restricted to using write-protection (for L2 when CPU dirty l= ogging, i.e. > - * PML, is enabled).=C2=A0 Use bits 52 and 53 to hold the type of A/D tr= acking that > + * PML, is enabled).=C2=A0 Use bits 60 and 61 to hold the type of A/D tr= acking that > =C2=A0 * is must be employed for a given TDP SPTE. > =C2=A0 * > =C2=A0 * Note, the "enabled" mask must be '0', as bits 62:52 are _reserve= d_ for PAE > @@ -29,7 +39,7 @@ > =C2=A0 * TDP with CPU dirty logging (PML).=C2=A0 If NPT ever gains PML-li= ke support, it > =C2=A0 * must be restricted to 64-bit KVM. > =C2=A0 */ > -#define SPTE_TDP_AD_SHIFT 52 > +#define SPTE_TDP_AD_SHIFT 60 > =C2=A0#define SPTE_TDP_AD_MASK (3ULL << SPTE_TDP_AD_SHIFT) > =C2=A0#define SPTE_TDP_AD_ENABLED (0ULL << SPTE_TDP_AD_SHIFT) > =C2=A0#define SPTE_TDP_AD_DISABLED (1ULL << SPTE_TDP_AD_SHIFT) > @@ -65,7 +75,7 @@ static_assert(SPTE_TDP_AD_ENABLED =3D=3D 0); > =C2=A0 */ > =C2=A0#define SHADOW_ACC_TRACK_SAVED_BITS_MASK (SPTE_EPT_READABLE_MASK | = \ > =C2=A0 =C2=A0 SPTE_EPT_EXECUTABLE_MASK) > -#define SHADOW_ACC_TRACK_SAVED_BITS_SHIFT 54 > +#define SHADOW_ACC_TRACK_SAVED_BITS_SHIFT 52 > =C2=A0#define SHADOW_ACC_TRACK_SAVED_MASK (SHADOW_ACC_TRACK_SAVED_BITS_MA= SK << \ > =C2=A0 SHADOW_ACC_TRACK_SAVED_BITS_SHIFT) > =C2=A0static_assert(!(SPTE_TDP_AD_MASK & SHADOW_ACC_TRACK_SAVED_MASK)); > @@ -84,8 +94,8 @@ static_assert(!(SPTE_TDP_AD_MASK & SHADOW_ACC_TRACK_SAV= ED_MASK)); > =C2=A0 * to not overlap the A/D type mask or the saved access bits of acc= ess-tracked > =C2=A0 * SPTEs when A/D bits are disabled. > =C2=A0 */ > -#define EPT_SPTE_HOST_WRITABLE BIT_ULL(57) > -#define EPT_SPTE_MMU_WRITABLE BIT_ULL(58) > +#define EPT_SPTE_HOST_WRITABLE BIT_ULL(53) > +#define EPT_SPTE_MMU_WRITABLE BIT_ULL(55) > =C2=A0 > =C2=A0static_assert(!(EPT_SPTE_HOST_WRITABLE & SPTE_TDP_AD_MASK)); > =C2=A0static_assert(!(EPT_SPTE_MMU_WRITABLE & SPTE_TDP_AD_MASK)); Reviewed-by: Maxim Levitsky Best regards, Maxim Levitsky