From: Sean Christopherson via Linux-kernel-mentees <linux-kernel-mentees@lists.linuxfoundation.org>
To: Coleman Dietsch <dietschc@csp.edu>
Cc: x86@kernel.org, kvm@vger.kernel.org,
Pavel Skripkin <paskripkin@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org,
syzbot+e54f930ed78eb0f85281@syzkaller.appspotmail.com,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [PATCH] KVM: x86/xen: Fix bug in kvm_xen_vcpu_set_attr()
Date: Thu, 28 Jul 2022 20:41:14 +0000 [thread overview]
Message-ID: <YuL0auT3lFhfQHeY@google.com> (raw)
In-Reply-To: <20220728194736.383727-1-dietschc@csp.edu>
Be more specific in the shortlog. "Fix a bug in XYZ" doesn't provide any info
about the bug itself, and can even become frustratingly stale if XYZ is renamed.
I believe we should end up with two patches (see below), e.g.
KVM: x86/xen: Initialize Xen timer only once (when it's NOT running)
and
KVM: x86/xen: Stop Xen timer before changing the IRQ vector
Note, I'm assuming timer_virq is a vector of some form, I haven't actually looked
that far into the code.
On Thu, Jul 28, 2022, Coleman Dietsch wrote:
> This crash appears to be happening when vcpu->arch.xen.timer is already set
Instead of saying "This crash", provide the actual splat (sanitized to make it
more readable). That way readers, reviewers, and archaeologists don't need to
open up a hyperlink to get details on what broken.
> and kvm_xen_init_timer(vcpu) is called.
Wrap changelogs at ~75 chars.
> During testing with the syzbot reproducer code it seemed apparent that the
> else if statement in the KVM_XEN_VCPU_ATTR_TYPE_TIMER switch case was not
> being reached, which is where the kvm_xen_stop_timer(vcpu) call is located.
Neither the shortlog nor the changelog actually says anything about what is actually
being changed.
> Link: https://syzkaller.appspot.com/bug?id=8234a9dfd3aafbf092cc5a7cd9842e3ebc45fc42
> Reported-and-tested-by: syzbot+e54f930ed78eb0f85281@syzkaller.appspotmail.com
> Signed-off-by: Coleman Dietsch <dietschc@csp.edu>
> ---
> arch/x86/kvm/xen.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index 610beba35907..4b4b985813c5 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -707,6 +707,12 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> break;
>
> case KVM_XEN_VCPU_ATTR_TYPE_TIMER:
> + /* Stop current timer if it is enabled */
> + if (kvm_xen_timer_enabled(vcpu)) {
> + kvm_xen_stop_timer(vcpu);
> + vcpu->arch.xen.timer_virq = 0;
> + }
> +
> if (data->u.timer.port) {
> if (data->u.timer.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL) {
> r = -EINVAL;
I'm not entirely sure this is correct. Probably doesn't matter, but there's a
subtle ABI change here in that invoking the ioctl with a "bad" priority will
cancel any existing timer.
And there appear to be two separate bugs: initializing the hrtimer while it's
running, and not canceling a running timer before changing timer_virq.
Calling kvm_xen_init_timer() on "every" KVM_XEN_VCPU_ATTR_TYPE_TIMER is odd and
unnecessary, it only needs to be called once during vCPU setup. If Xen doesn't
have such a hook, then a !ULL check can be done on vcpu->arch.xen.timer.function
to initialize the timer on-demand.
With that out of the way, the code can be streamlined a bit, e.g. something like
this?
case KVM_XEN_VCPU_ATTR_TYPE_TIMER:
if (data->u.timer.port &&
data->u.timer.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL) {
r = -EINVAL;
break;
}
if (!vcpu->arch.xen.timer.function)
kvm_xen_init_timer(vcpu);
/* Stop the timer (if it's running) before changing the vector. */
kvm_xen_stop_timer(vcpu);
vcpu->arch.xen.timer_virq = data->u.timer.port;
if (data->u.timer.port && data->u.timer.expires_ns)
kvm_xen_start_timer(vcpu, data->u.timer.expires_ns,
data->u.timer.expires_ns -
get_kvmclock_ns(vcpu->kvm));
r = 0;
break;
> @@ -720,9 +726,6 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> kvm_xen_start_timer(vcpu, data->u.timer.expires_ns,
> data->u.timer.expires_ns -
> get_kvmclock_ns(vcpu->kvm));
> - } else if (kvm_xen_timer_enabled(vcpu)) {
> - kvm_xen_stop_timer(vcpu);
> - vcpu->arch.xen.timer_virq = 0;
> }
>
> r = 0;
> --
> 2.34.1
>
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
next prev parent reply other threads:[~2022-07-28 20:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 19:47 [PATCH] KVM: x86/xen: Fix bug in kvm_xen_vcpu_set_attr() Coleman Dietsch
2022-07-28 20:41 ` Sean Christopherson via Linux-kernel-mentees [this message]
2022-07-28 22:49 ` Coleman Dietsch
2022-07-29 7:41 ` Greg KH
2022-07-29 23:29 ` Coleman Dietsch
2022-08-08 13:51 ` David Woodhouse
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=YuL0auT3lFhfQHeY@google.com \
--to=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dietschc@csp.edu \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paskripkin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=syzbot+e54f930ed78eb0f85281@syzkaller.appspotmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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).