[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230628170339.GE3436214@ls.amr.corp.intel.com>
Date: Wed, 28 Jun 2023 10:03:39 -0700
From: Isaku Yamahata <isaku.yamahata@...il.com>
To: Yuan Yao <yuan.yao@...ux.intel.com>
Cc: isaku.yamahata@...el.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, isaku.yamahata@...il.com,
Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com,
Sean Christopherson <seanjc@...gle.com>,
Sagi Shahar <sagis@...gle.com>,
David Matlack <dmatlack@...gle.com>,
Kai Huang <kai.huang@...el.com>,
Zhi Wang <zhi.wang.linux@...il.com>, chen.bo@...el.com,
linux-coco@...ts.linux.dev,
Chao Peng <chao.p.peng@...ux.intel.com>,
Ackerley Tng <ackerleytng@...gle.com>,
Vishal Annapurve <vannapurve@...gle.com>,
Michael Roth <michael.roth@....com>
Subject: Re: [RFC PATCH v2 5/6] KVM: Add flags to struct kvm_gfn_range
On Wed, Jun 28, 2023 at 02:41:56PM +0800,
Yuan Yao <yuan.yao@...ux.intel.com> wrote:
> On Thu, Jun 22, 2023 at 04:16:29PM -0700, isaku.yamahata@...el.com wrote:
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> >
> > Add flags to strut kvm_gfn_range to indicate who triggered the callback
> > and new memory attributes.
> >
> > TDX needs to know the reason for a callback by kvm_unmap_gfn_range(). mmu
> > notifier, set memory attributes ioctl or KVM gmem callback. With TDX,
> > zapping a private page from the encrypted page table and adding the page
> > back to the same private GPA results in zeroing the page, and the guest has
> > to accept the page again. On the change of memory attribute from private
>
> Is this part used to explains why on MMU notifier only shared pages should
> be zapped ?
Right for TDX.
> > to shared, zapping the GPA range irrespective to private-or-shared and
> > expecting the fault doesn't work for TDX. Instead, zap shared pages only
> > and keep the private pages. Concretely
>
> Do you mean:
>
> On the change of memory attribute, zapping the GPA range irrespective to
> private-or-shared and expecting that the EPT mapping for attribute converts
> to doesn't exist at the time of changing the attribute, zap the "from"
> attribute range only and ignore the "to" attribute.
That's what I meant. The requirement seems specific to TDX.
I'll update this patch following the suggestion by Sean. [1]
[1] https://lore.kernel.org/all/ZJX0hk+KpQP0KUyB@google.com/
--
Isaku Yamahata <isaku.yamahata@...il.com>
Powered by blists - more mailing lists