From: Yan Zhao <yan.y.zhao@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: <seanjc@google.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <rick.p.edgecombe@intel.com>,
<kai.huang@intel.com>, <adrian.hunter@intel.com>,
<reinette.chatre@intel.com>, <xiaoyao.li@intel.com>,
<tony.lindgren@intel.com>, <binbin.wu@linux.intel.com>,
<dmatlack@google.com>, <isaku.yamahata@intel.com>,
<isaku.yamahata@gmail.com>
Subject: Re: [PATCH 0/7] KVM: TDX SEPT SEAMCALL retry
Date: Thu, 16 Jan 2025 08:52:10 +0800 [thread overview]
Message-ID: <Z4hYOviOCaOcpxsw@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <cd099216-5fc7-4a79-8d35-b87c356e122b@redhat.com>
On Wed, Jan 15, 2025 at 05:43:51PM +0100, Paolo Bonzini wrote:
> On 1/13/25 03:09, Yan Zhao wrote:
> > This series aims to provide a clean solution to avoid the blind retries in
> > the previous hack [1] in "TDX MMU Part 2," following the initial
> > discussions to [2], further discussions in the RFC, and the PUCK [3].
> >
> > A full analysis of the lock status for each SEAMCALL relevant to KVM is
> > available at [4].
> >
> > This series categorizes the SEPT-related SEAMCALLs (used for page
> > installation and uninstallation) into three groups:
> >
> > Group 1: tdh_mem_page_add().
> > - Invoked only during TD build time.
> > - Proposal: Return -EBUSY on TDX_OPERAND_BUSY.
> > - Patch 1.
> >
> > Group 2: tdh_mem_sept_add(), tdh_mem_page_aug().
> > - Invoked for TD runtime page installation.
> > - Proposal: Retry locally in the TDX EPT violation handler for
> > RET_PF_RETRY.
> > - Patches 2-3.
> >
> > Group 3: tdh_mem_range_block(), tdh_mem_track(), tdh_mem_page_remove().
> > - Invoked for page uninstallation, with KVM mmu_lock held for write.
> > - Proposal: Kick off vCPUs and no vCPU entry on TDX_OPERAND_BUSY.
> > - Patch 4.
> >
> > Patches 5/6/7 are fixup patches:
> > Patch 5: Return -EBUSY instead of -EAGAIN when tdh_mem_sept_add() is busy.
> > Patch 6: Remove the retry loop for tdh_phymem_page_wbinvd_hkid().
> > Patch 7: Warn on force_immediate_exit in tdx_vcpu_run().
> >
> > Code base: kvm-coco-queue 2f30b837bf7b.
> > Applies to the tail since the dependence on
> > commit 8e801e55ba8f ("KVM: TDX: Handle EPT violation/misconfig exit"),
> >
> > Thanks
> > Yan
> >
> > RFC --> v1:
> > - Split patch 1 in RFC into patches 1,2,3,5, and add new fixup patches 6/7.
> > - Add contention analysis of tdh_mem_page_add() in patch 1 log.
> > - Provide justification in patch 2 log and add checks for RET_PF_CONTINUE.
> > - Use "a per-VM flag wait_for_sept_zap + KVM_REQ_OUTSIDE_GUEST_MODE"
> > instead of a arch-specific request to prevent vCPUs from TD entry in patch 4
> > (Sean).
> >
> > RFC: https://lore.kernel.org/all/20241121115139.26338-1-yan.y.zhao@intel.com
> > [1] https://lore.kernel.org/all/20241112073909.22326-1-yan.y.zhao@intel.com
> > [2] https://lore.kernel.org/kvm/20240904030751.117579-10-rick.p.edgecombe@intel.com/
> > [3] https://drive.google.com/drive/folders/1k0qOarKuZXpzRsKDtVeC5Lpl9-amJ6AJ?resourcekey=0-l9uVpVEBC34Uar1ReaqisQ
> > [4] https://lore.kernel.org/kvm/ZuP5eNXFCljzRgWo@yzhao56-desk.sh.intel.com
>
> Thanks, I applied this to kvm-coco-queue and patch 2 to kvm/queue. It is
> spread all over the branch to make the dependencies clearer, so here's some
> ideas on how to include these.
>
> Patches 6 and 7 should be squashed into the respective bases, as they have
> essentially no functional change.
>
> For the rest, patch 1 can be treated as a fixup too, and I have two
> proposals.
>
> First possibility, separate series:
> * patches 1+5 are merged into a single patch.
> * patches 3+4 become two more patches in this separate series
>
> Second possibility, squash everything:
> * patches 1+5 are squashed into the respective bases
> * patches 3+4 are included in the EPT violation series
>
> On the PUCK call I said that I prefer the first, mostly to keep track of who
> needs to handle TDX_OPERAND_BUSY, but if it makes it easier for Yan then
> feel free to go for the second.
Thank you, Paolo.
I'm ok with either way.
For the first, hmm, a bad thing is that though
tdh_mem_sept_add()/tdh_mem_page_aug()/tdh_mem_sept_add() all need to handle
TDX_OPERAND_BUSY, the one for tdh_mem_page_aug() has already been squashed
into the MMU part 2.
If you like, maybe I can extract the one for tdh_mem_page_aug() and merge it
with 1+5.
Then since 3 depends on EPT violation, for the first, 3+4 can also be included
in the EPT violation series, right?
>
> Paolo
>
> > Yan Zhao (7):
> > KVM: TDX: Return -EBUSY when tdh_mem_page_add() encounters
> > TDX_OPERAND_BUSY
> > KVM: x86/mmu: Return RET_PF* instead of 1 in kvm_mmu_page_fault()
> > KVM: TDX: Retry locally in TDX EPT violation handler on RET_PF_RETRY
> > KVM: TDX: Kick off vCPUs when SEAMCALL is busy during TD page removal
> > fixup! KVM: TDX: Implement hooks to propagate changes of TDP MMU
> > mirror page table
> > fixup! KVM: TDX: Implement hooks to propagate changes of TDP MMU
> > mirror page table
> > fixup! KVM: TDX: Implement TDX vcpu enter/exit path
> >
> > arch/x86/kvm/mmu/mmu.c | 10 ++-
> > arch/x86/kvm/mmu/mmu_internal.h | 12 ++-
> > arch/x86/kvm/vmx/tdx.c | 135 ++++++++++++++++++++++++++------
> > arch/x86/kvm/vmx/tdx.h | 7 ++
> > 4 files changed, 134 insertions(+), 30 deletions(-)
> >
>
>
next prev parent reply other threads:[~2025-01-16 0:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 2:09 Yan Zhao
2025-01-13 2:10 ` [PATCH 1/7] KVM: TDX: Return -EBUSY when tdh_mem_page_add() encounters TDX_OPERAND_BUSY Yan Zhao
2025-01-14 22:24 ` Edgecombe, Rick P
2025-01-15 4:59 ` Yan Zhao
2025-01-13 2:11 ` [PATCH 2/7] KVM: x86/mmu: Return RET_PF* instead of 1 in kvm_mmu_page_fault() Yan Zhao
2025-01-14 22:24 ` Edgecombe, Rick P
2025-01-15 4:58 ` Yan Zhao
2025-01-13 2:12 ` [PATCH 3/7] KVM: TDX: Retry locally in TDX EPT violation handler on RET_PF_RETRY Yan Zhao
2025-01-17 21:14 ` Sean Christopherson
2025-01-20 8:05 ` Yan Zhao
2025-01-25 1:23 ` Sean Christopherson
2025-01-27 9:24 ` Yan Zhao
2025-01-27 17:04 ` Sean Christopherson
2025-02-05 7:34 ` Yan Zhao
2025-01-13 2:12 ` [PATCH 4/7] KVM: TDX: Kick off vCPUs when SEAMCALL is busy during TD page removal Yan Zhao
2025-01-16 6:23 ` Binbin Wu
2025-01-16 6:28 ` Binbin Wu
2025-01-16 8:18 ` Yan Zhao
2025-01-13 2:13 ` [PATCH 5/7] fixup! KVM: TDX: Implement hooks to propagate changes of TDP MMU mirror page table Yan Zhao
2025-01-16 6:30 ` Binbin Wu
2025-01-13 2:13 ` [PATCH 6/7] " Yan Zhao
2025-01-13 2:13 ` [PATCH 7/7] fixup! KVM: TDX: Implement TDX vcpu enter/exit path Yan Zhao
2025-01-14 22:27 ` [PATCH 0/7] KVM: TDX SEPT SEAMCALL retry Edgecombe, Rick P
2025-01-15 16:43 ` Paolo Bonzini
2025-01-16 0:52 ` Yan Zhao [this message]
2025-01-16 11:07 ` Paolo Bonzini
2025-01-17 9:52 ` Yan Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4hYOviOCaOcpxsw@yzhao56-desk.sh.intel.com \
--to=yan.y.zhao@intel.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=dmatlack@google.com \
--cc=isaku.yamahata@gmail.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®