[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3936872ab5bd396051a67f46b92a44e4b35fba45.camel@intel.com>
Date: Wed, 11 Sep 2024 16:29:57 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, "Zhao, Yan Y"
<yan.y.zhao@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>, "nik.borisov@...e.com"
<nik.borisov@...e.com>, "dmatlack@...gle.com" <dmatlack@...gle.com>
Subject: Re: [PATCH 05/21] KVM: VMX: Teach EPT violation helper about private
mem
On Wed, 2024-09-11 at 16:52 +0800, Chao Gao wrote:
> > + /*
> > + * Don't rely on GFN's attribute tracking xarray to prevent EPT
> > violation
> > + * loops.
> > + */
>
> The comment seems a bit odd to me. We cannot use the gfn attribute from the
> attribute xarray simply because here we need to determine if *this access* is
> to private memory, which may not match the gfn attribute. Even if there are
> other ways to prevent an infinite EPT violation loop, we still need to check
> the shared bit in the faulting GPA.
Yea this comment is not super informative. We can probably just drop it.
Powered by blists - more mailing lists