From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Alex Williamson <alex.williamson@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Peter Xu <peterx@redhat.com>, Pei Zhang <pezhang@redhat.com>
Subject: Re: [patch 4/4] KVM: VMX: update vcpu posted-interrupt descriptor when assigning device
Date: Mon, 24 May 2021 14:53:29 -0300 [thread overview]
Message-ID: <20210524175329.GA19468@fuller.cnet> (raw)
In-Reply-To: <e929da71-8f7d-52b2-2a71-30cb078535d3@redhat.com>
On Mon, May 24, 2021 at 05:55:18PM +0200, Paolo Bonzini wrote:
> On 10/05/21 19:26, Marcelo Tosatti wrote:
> > +void vmx_pi_start_assignment(struct kvm *kvm)
> > +{
> > + struct kvm_vcpu *vcpu;
> > + int i;
> > +
> > + if (!irq_remapping_cap(IRQ_POSTING_CAP))
> > + return;
> > +
> > + /*
> > + * Wakeup will cause the vCPU to bail out of kvm_vcpu_block() and
> > + * go back through vcpu_block().
> > + */
> > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > + if (!kvm_vcpu_apicv_active(vcpu))
> > + continue;
> > +
> > + kvm_vcpu_wake_up(vcpu);
>
> Would you still need the check_block callback, if you also added a
> kvm_make_request(KVM_REQ_EVENT)?
>
> In fact, since this is entirely not a hot path, can you just do
> kvm_make_all_cpus_request(kvm, KVM_REQ_EVENT) instead of this loop?
>
> Thanks,
>
> Paolo
Hi Paolo,
Don't think so:
int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
{
return kvm_vcpu_running(vcpu) || kvm_vcpu_has_events(vcpu);
}
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
int ret = -EINTR;
int idx = srcu_read_lock(&vcpu->kvm->srcu);
if (kvm_arch_vcpu_runnable(vcpu)) {
kvm_make_request(KVM_REQ_UNHALT, vcpu); <---- don't want KVM_REQ_UNHALT
goto out;
}
if (kvm_cpu_has_pending_timer(vcpu))
goto out;
if (signal_pending(current))
goto out;
ret = 0;
out:
srcu_read_unlock(&vcpu->kvm->srcu, idx);
return ret;
}
See previous discussion:
Date: Wed, 12 May 2021 14:41:56 +0000
From: Sean Christopherson <seanjc@google.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Peter Xu <peterx@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org, Alex Williamson
<alex.williamson@redhat.com>, Pei Zhang <pezhang@redhat.com>
Subject: Re: [patch 4/4] KVM: VMX: update vcpu posted-interrupt descriptor when assigning device
On Tue, May 11, 2021, Marcelo Tosatti wrote:
> > The KVM_REQ_UNBLOCK patch will resume execution even any such event
>
> even without any such event
>
> > occuring. So the behaviour would be different from baremetal.
I agree with Marcelo, we don't want to spuriously unhalt the vCPU. It's legal,
albeit risky, to do something like
hlt
/* #UD to triple fault if this CPU is awakened. */
ud2
when offlining a CPU, in which case the spurious wake event will crash the guest.
next prev parent reply other threads:[~2021-05-24 18:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 17:26 [patch 0/4] VMX: configure posted interrupt descriptor when assigning device (v3) Marcelo Tosatti
2021-05-10 17:26 ` [patch 1/4] KVM: x86: add start_assignment hook to kvm_x86_ops Marcelo Tosatti
2021-05-11 16:26 ` Peter Xu
2021-05-11 17:29 ` Marcelo Tosatti
2021-05-10 17:26 ` [patch 2/4] KVM: add arch specific vcpu_check_block callback Marcelo Tosatti
2021-05-10 17:26 ` [patch 3/4] KVM: x86: implement kvm_arch_vcpu_check_block callback Marcelo Tosatti
2021-05-10 17:26 ` [patch 4/4] KVM: VMX: update vcpu posted-interrupt descriptor when assigning device Marcelo Tosatti
2021-05-24 15:55 ` Paolo Bonzini
2021-05-24 17:53 ` Marcelo Tosatti [this message]
2021-05-25 11:58 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2021-05-11 23:57 [patch 0/4] VMX: configure posted interrupt descriptor when assigning device (v4) Marcelo Tosatti
2021-05-11 23:57 ` [patch 4/4] KVM: VMX: update vcpu posted-interrupt descriptor when assigning device Marcelo Tosatti
2021-05-07 13:06 [patch 0/4] VMX: configure posted interrupt " Marcelo Tosatti
2021-05-07 13:06 ` [patch 4/4] KVM: VMX: update vcpu posted-interrupt " Marcelo Tosatti
2021-05-07 17:22 ` Sean Christopherson
2021-05-07 19:29 ` Peter Xu
2021-05-07 22:08 ` Marcelo Tosatti
2021-05-11 14:39 ` Peter Xu
2021-05-11 14:51 ` Marcelo Tosatti
2021-05-11 16:19 ` Peter Xu
2021-05-11 17:18 ` Marcelo Tosatti
2021-05-11 21:35 ` Peter Xu
2021-05-11 23:51 ` Marcelo Tosatti
2021-05-12 0:02 ` Marcelo Tosatti
2021-05-12 0:38 ` Peter Xu
2021-05-12 11:10 ` Marcelo Tosatti
2021-05-12 14:41 ` Sean Christopherson
2021-05-12 15:34 ` Peter Xu
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=20210524175329.GA19468@fuller.cnet \
--to=mtosatti@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=pezhang@redhat.com \
--cc=seanjc@google.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.