All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v6 02/20] KVM: VMX: Save guest EGPRs in VCPU cache
Date: Wed, 29 Jul 2026 20:05:42 +0000	[thread overview]
Message-ID: <20260729200543.5868C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729191656.598771-3-chang.seok.bae@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Live migration of APX-enabled guests results in silent guest state corruption (loss of EGPRs) due to a conflict between manual VCPU register caching and XSAVE state management.
--

--- Patch [2]: [PATCH v6 02/20] KVM: VMX: Save guest EGPRs in VCPU cache ---
commit 8d65deb78b6fe07e8687f8aa1c29bd4e028cfac7
Author: Chang S. Bae <chang.seok.bae@intel.com>

KVM: VMX: Save guest EGPRs in VCPU cache
    
This patch saves and restores the guest EGPRs on VM exit/entry if the system
supports Advanced Performance Extensions (APX). It saves the EGPR state into
vcpu->arch.regs and clears the hardware registers on exit.

Link: https://lore.kernel.org/adPRA4ZhnvbaXSn0@google.com

> diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S
> index 00d807505fc88..702d86ade6b1d 100644
> --- a/arch/x86/kvm/vmx/vmenter.S
> +++ b/arch/x86/kvm/vmx/vmenter.S

[ ... ]

> @@ -193,8 +204,24 @@ SYM_INNER_LABEL_ALIGN(vmx_vmexit, SYM_L_GLOBAL)
>  	mov %_ASM_BX, %_ASM_AX
>  
>  	/* Pop our saved arguments from the stack */
> -	pop %_ASM_BX
> -	pop %_ASM_BX
> +	pop %_ASM_BX	/* @flags */
> +	pop %_ASM_DI	/* @vmx */
> +
> +#ifdef CONFIG_KVM_APX
> +	ALTERNATIVE "jmp .Lclear_egprs_done", "", X86_FEATURE_APX
> +	test	$KVM_ENTER_EGPR_SWITCH, %_ASM_BX
> +	jz	.Lclear_egprs_done
> +	/*
> +	 * Unlike legacy GPRs, saving could be conditional here on VM-Fail,
> +	 * which however isn't in fastpath. Instead, simply saving EGPRs always.
> +	 */
> +	STORE_REGS %_ASM_DI, VMX_vcpu_arch_regs, \
> +		   %r16, %r17, %r18, %r19, %r20, %r21, %r22, %r23, \
> +		   %r24, %r25, %r26, %r27, %r28, %r29, %r30, %r31
> +	CLEAR_REGS %r16d, %r17d, %r18d, %r19d, %r20d, %r21d, %r22d, %r23d, \
> +		   %r24d, %r25d, %r26d, %r27d, %r28d, %r29d, %r30d, %r31d

[Severity: High]
Does clearing the hardware EGPRs here cause state loss during live migration?

When KVM later unloads the vCPU and calls kvm_put_guest_fpu(), it uses the
hardware XSAVES instruction to capture the guest's FPU/extended state into
vcpu->arch.guest_fpu. Because the hardware EGPRs were zeroed here, XSAVES
populates the APX component of the XSAVE buffer with zeros.

When userspace subsequently calls KVM_GET_XSAVE2 to serialize the state for
migration, it exports the zeroed guest_fpu without synchronizing the true
register values from vcpu->arch.regs.

Additionally, userspace cannot fallback to KVM_GET_REGS because the UAPI
struct kvm_regs hasn't been updated to include R16-R31.

Could this lead to APX-enabled guests resuming with zeroed EGPRs after a
migration?

> +.Lclear_egprs_done:
> +#endif
>  
>  	/* ... and then the callee-save registers */
>  	pop %_ASM_BX

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729191656.598771-1-chang.seok.bae@intel.com?part=2

  reply	other threads:[~2026-07-29 20:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 19:16 [PATCH v6 00/20] KVM: x86: Enable APX for guests Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 01/20] KVM: x86: Extend VCPU registers for EGPRs Chang S. Bae
2026-07-29 20:04   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 02/20] KVM: VMX: Save guest EGPRs in VCPU cache Chang S. Bae
2026-07-29 20:05   ` sashiko-bot [this message]
2026-07-29 19:16 ` [PATCH v6 03/20] KVM: x86: Support APX state for XSAVE ABI Chang S. Bae
2026-07-29 20:31   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 04/20] KVM: VMX: Refactor VMX instruction information access Chang S. Bae
2026-07-29 20:02   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 05/20] KVM: VMX: Refactor instruction information decoding Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 06/20] KVM: VMX: Remove unused control-register access defines Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 07/20] KVM: VMX: Refactor register index retrieval from exit qualification Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 08/20] KVM: VMX: Support instruction information extension Chang S. Bae
2026-07-29 20:00   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 09/20] KVM: nVMX: Propagate extended instruction information Chang S. Bae
2026-07-29 20:01   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 10/20] KVM: x86: Support EGPR accessing and tracking for emulator Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 11/20] KVM: x86: Handle EGPR index and REX2-incompatible opcodes Chang S. Bae
2026-07-29 20:04   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 12/20] KVM: x86: Support REX2-prefixed opcode decode Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 13/20] KVM: x86: Reject EVEX-prefixed instructions Chang S. Bae
2026-07-29 19:58   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 14/20] KVM: x86: Move KVM_SUPPORTED_{XCR0,XSS} into kvm_x86_vendor_init() Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 15/20] KVM: x86: Guard valid XCR0.APX settings Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 16/20] KVM: x86: Add APX to supported XCR0 Chang S. Bae
2026-07-29 20:06   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 17/20] KVM: x86: Expose APX foundation feature to userspace Chang S. Bae
2026-07-29 19:16 ` [PATCH v6 18/20] KVM: x86: Expose APX sub-features " Chang S. Bae
2026-07-29 20:01   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 19/20] KVM: x86: selftests: Add APX state and ABI test Chang S. Bae
2026-07-29 20:08   ` sashiko-bot
2026-07-29 19:16 ` [PATCH v6 20/20] KVM: x86: selftests: Add APX state handling and XCR0 sanity checks Chang S. Bae

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=20260729200543.5868C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=chang.seok.bae@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.