[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YPd1Q1ppmKng67tk@google.com>
Date: Wed, 21 Jul 2021 10:15:47 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Will Deacon <will@...nel.org>,
Suleiman Souhlal <suleiman@...gle.com>,
Joel Fernandes <joelaf@...gle.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCHv2 4/4] arm64: add host pv-vcpu-state support
On (21/07/12 17:24), Marc Zyngier wrote:
> >
> > void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> > {
> > + kvm_update_vcpu_preempted(vcpu, true);
>
> This doesn't look right. With this, you are now telling the guest that
> a vcpu that is blocked on WFI is preempted. This really isn't the
> case, as it has voluntarily entered a low-power mode while waiting for
> an interrupt. Indeed, the vcpu isn't running. A physical CPU wouldn't
> be running either.
I suppose you are talking about kvm_vcpu_block(). Well, it checks
kvm_vcpu_check_block() but then it simply schedule() out the vcpu
process, which does look like "the vcpu is preempted". Once we
sched_in() that vcpu process again we mark it as non-preempted,
even though it remains in kvm wfx handler. Why isn't it right?
Another call path is iret:
<iret>
__schedule()
context_switch()
prepare_task_switch()
fire_sched_in_preempt_notifiers()
kvm_sched_out()
kvm_arch_vcpu_put()
Powered by blists - more mailing lists