[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d530621e89dae01dc27bbdc8a97a1935b0827699.camel@amd.com>
Date: Wed, 9 Jul 2025 13:40:16 +0000
From: "Shah, Amit" <Amit.Shah@....com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "x86@...nel.org" <x86@...nel.org>, "dave.hansen@...ux.intel.com"
<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>, "tglx@...utronix.de"
<tglx@...utronix.de>, "bp@...en8.de" <bp@...en8.de>, "kvm@...r.kernel.org"
<kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"jon@...anix.com" <jon@...anix.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 06/18] KVM: VMX: Wire up Intel MBEC enable/disable
logic
On Tue, 2025-06-17 at 07:13 -0700, Sean Christopherson wrote:
> [snipped nested page walk overview]
Thanks a lot for this!
>
> Side topic, someone should check with the AMD architects as to
> whether or not
> GMET depends on EFER.NXE=1. The APM says that all NPT mappings are
> executable
> if EFER.NXE=0 in the host (where the "host" is L1 when dealing with
> nested NPT).
> To me, that implies GMET is effectively ignored if EFER.NXE=0.
>
> Similarly, if the EFER.NXE bit is cleared for the host, all nested
> page table
> mappings are executable at the underlying nested level.
The "effective NX" computation includes EFER.NXE. If that's 0, GMET is
still active and depends on the U/S bit if enabled, as mentioned in the
APM.
Cheers,
Amit
Powered by blists - more mailing lists