kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Chenyi Qiang <chenyi.qiang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND v4 2/2] KVM: VMX: Enable bus lock VM exit
Date: Tue, 20 Oct 2020 15:19:45 -0700	[thread overview]
Message-ID: <20201020221943.GB9031@linux.intel.com> (raw)
In-Reply-To: <20201012033542.4696-3-chenyi.qiang@intel.com>

On Mon, Oct 12, 2020 at 11:35:42AM +0800, Chenyi Qiang wrote:
> @@ -6138,6 +6149,26 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
>  	return 0;
>  }
>  
> +static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
> +{
> +	int ret = __vmx_handle_exit(vcpu, exit_fastpath);
> +
> +	/*
> +	 * Even when current exit reason is handled by KVM internally, we
> +	 * still need to exit to user space when bus lock detected to inform
> +	 * that there is a bus lock in guest.
> +	 */
> +	if (to_vmx(vcpu)->exit_reason.bus_lock_detected) {
> +		if (ret > 0)
> +			vcpu->run->exit_reason = KVM_EXIT_BUS_LOCK;
> +		else
> +			vcpu->run->flags |= KVM_RUN_BUS_LOCK;

This should always set flags.KVM_RUN_BUS_LOCK, e.g. so that userspace can
always check flags.KVM_RUN_BUS_LOCK instead of having to check both the flag
and the exit reason.  As is, it's really bad because the flag is undefined,
which could teach userspace to do the wrong thing.

> +		return 0;
> +	}
> +	vcpu->run->flags &= ~KVM_RUN_BUS_LOCK;

Hmm, I feel like explicitly clearing flags is should be unnecessary.  By
that, I mean that's it's necessary in the current patch, bit I think we should
figure out how to make that not be the case.  With the current approach, every
chunk of code that needs to set a flag also needs to clear it, which increases
the odds of missing a case and ending up with a flag in an undefined state.

The easiest way I can think of is to add another prep patch that zeros
run->flags at the beginning of kvm_arch_vcpu_ioctl_run(), and changes
post_kvm_run_save() to do:

	if (is_smm(vcpu))
		kvm_run->flags |= KVM_RUN_X86_SMM;

Then this patch can omit clearing KVM_RUN_BUS_LOCK, and doesn't have to touch
the SMM flag.

> +	return ret;
> +}
> +
>  /*
>   * Software based L1D cache flush which is used when microcode providing
>   * the cache control MSR is not loaded.

  reply	other threads:[~2020-10-20 22:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12  3:35 [RESEND v4 0/2] Add bus lock VM exit support Chenyi Qiang
2020-10-12  3:35 ` [RESEND v4 1/2] KVM: VMX: Convert vcpu_vmx.exit_reason to a union Chenyi Qiang
2020-10-20 22:01   ` Sean Christopherson
2020-10-26  5:31     ` Chenyi Qiang
2020-10-12  3:35 ` [RESEND v4 2/2] KVM: VMX: Enable bus lock VM exit Chenyi Qiang
2020-10-20 22:19   ` Sean Christopherson [this message]
2020-10-26  5:31     ` Chenyi Qiang

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=20201020221943.GB9031@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=chenyi.qiang@intel.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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;
as well as URLs for NNTP newsgroup(s).