[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCOHP3B2sRVut3By@google.com>
Date: Tue, 13 May 2025 10:54:07 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Jon Kohler <jon@...anix.com>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
"hpa@...or.com" <hpa@...or.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Sergey Dyasli <sergey.dyasli@...anix.com>
Subject: Re: [RFC PATCH 15/18] KVM: x86/mmu: Extend make_spte to understand MBEC
On Tue, May 13, 2025, Jon Kohler wrote:
> > I would straight up WARN, because it should be impossible to reach this code with
> > ACC_USER_EXEC_MASK set. In fact, this entire blob of code should be #ifdef'd
> > out for PTTYPE_EPT. AFAICT, the only reason it doesn't break nEPT is because
> > its impossible to have a WRITE EPT violation without READ (a.k.a. USER) being
> > set.
>
> Would you like me to send a separate patch out for that to clean up as
> I go? Or make such ifdef’ery as part of this series?
I'll send a patch. It's not at all urgent, not a hard dependency for MBEC, the
comment(s) needs to be rewritten, I want to do an audit of paging_tmpl.h to see
if there is more code that'd be worth #idef'ing out for nEPT.
Powered by blists - more mailing lists