[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de3cb02ae9e639f423ae47ef2fad1e89aa9dd3d8.camel@intel.com>
Date: Wed, 15 May 2024 16:12:37 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"sagis@...gle.com" <sagis@...gle.com>, "isaku.yamahata@...il.com"
<isaku.yamahata@...il.com>, "Aktas, Erdem" <erdemaktas@...gle.com>, "Zhao,
Yan Y" <yan.y.zhao@...el.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "dmatlack@...gle.com"
<dmatlack@...gle.com>
Subject: Re: [PATCH 08/16] KVM: x86/mmu: Bug the VM if kvm_zap_gfn_range() is
called for TDX
On Wed, 2024-05-15 at 09:02 -0700, Sean Christopherson wrote:
> > Or most specifically, we only need this zapping if we *try* to have
> > consistent
> > cache attributes between private and shared. In the non-coherent DMA case we
> > can't have them be consistent because TDX doesn't support changing the
> > private
> > memory in this way.
>
> Huh? That makes no sense. A physical page can't be simultaneously mapped
> SHARED
> and PRIVATE, so there can't be meaningful cache attribute aliasing between
> private
> and shared EPT entries.
>
> Trying to provide consistency for the GPA is like worrying about having
> matching
> PAT entires for the virtual address in two different processes.
No, not matching between the private and shared mappings of the same page. The
whole private memory will be WB, and the whole shared half will honor PAT.
Powered by blists - more mailing lists