From: Paolo Bonzini <pbonzini@redhat.com>
To: Yang Zhong <yang.zhong@intel.com>, kvm@vger.kernel.org
Cc: seanjc@google.com
Subject: Re: [PATCH 1/2] KVM: VMX: Keep registers read/write consistent with definition
Date: Thu, 22 Apr 2021 12:38:19 +0200 [thread overview]
Message-ID: <5b5c9467-6358-66fb-47dd-cd8721ebe2f0@redhat.com> (raw)
In-Reply-To: <20210422093436.78683-2-yang.zhong@intel.com>
On 22/04/21 11:34, Yang Zhong wrote:
> The kvm_cache_regs.h file has defined inline functions for those general
> purpose registers and pointer register read/write operations, we need keep
> those related registers operations consistent with header file definition
> in the VMX side.
>
> Signed-off-by: Yang Zhong <yang.zhong@intel.com>
> ---
> arch/x86/kvm/vmx/vmx.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 29b40e092d13..d56505fc7a71 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -2266,10 +2266,10 @@ static void vmx_cache_reg(struct kvm_vcpu *vcpu, enum kvm_reg reg)
>
> switch (reg) {
> case VCPU_REGS_RSP:
> - vcpu->arch.regs[VCPU_REGS_RSP] = vmcs_readl(GUEST_RSP);
> + kvm_rsp_write(vcpu, vmcs_readl(GUEST_RSP));
> break;
> case VCPU_REGS_RIP:
> - vcpu->arch.regs[VCPU_REGS_RIP] = vmcs_readl(GUEST_RIP);
> + kvm_rip_write(vcpu, vmcs_readl(GUEST_RIP));
> break;
This is on purpose, because you don't want to mark those register dirty.
Likewise, in the case below it's more confusing to go through the helper
because it checks kvm_register_is_available and calls vmx_cache_reg if
false.
Because these functions are the once that handle the caching, it makes
sense for them not to use the helpers.
Paolo
> case VCPU_EXREG_PDPTR:
> if (enable_ept)
> @@ -4432,7 +4432,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
>
> vmx->msr_ia32_umwait_control = 0;
>
> - vmx->vcpu.arch.regs[VCPU_REGS_RDX] = get_rdx_init_val();
> + kvm_rdx_write(&vmx->vcpu, get_rdx_init_val());
> vmx->hv_deadline_tsc = -1;
> kvm_set_cr8(vcpu, 0);
>
> @@ -6725,9 +6725,10 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
> WARN_ON_ONCE(vmx->nested.need_vmcs12_to_shadow_sync);
>
> if (kvm_register_is_dirty(vcpu, VCPU_REGS_RSP))
> - vmcs_writel(GUEST_RSP, vcpu->arch.regs[VCPU_REGS_RSP]);
> + vmcs_writel(GUEST_RSP, kvm_rsp_read(vcpu));
> +
> if (kvm_register_is_dirty(vcpu, VCPU_REGS_RIP))
> - vmcs_writel(GUEST_RIP, vcpu->arch.regs[VCPU_REGS_RIP]);
> + vmcs_writel(GUEST_RIP, kvm_rip_read(vcpu));
>
> cr3 = __get_current_cr3_fast();
> if (unlikely(cr3 != vmx->loaded_vmcs->host_state.cr3)) {
>
next prev parent reply other threads:[~2021-04-22 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 9:34 [PATCH 0/2] Cleanup the registers read/write access Yang Zhong
2021-04-22 9:34 ` [PATCH 1/2] KVM: VMX: Keep registers read/write consistent with definition Yang Zhong
2021-04-22 10:38 ` Paolo Bonzini [this message]
2021-04-24 12:31 ` Yang Zhong
2021-04-22 9:34 ` [PATCH 2/2] KVM: SVM: " Yang Zhong
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=5b5c9467-6358-66fb-47dd-cd8721ebe2f0@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=seanjc@google.com \
--cc=yang.zhong@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 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.