From: Oliver Upton <oupton@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <Alexandru.Elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Peter Shier <pshier@google.com>,
Shakeel Butt <shakeelb@google.com>,
Guangyu Shi <guangyus@google.com>
Subject: Re: [PATCH v2 3/3] KVM: arm64: Use generic KVM xfer to guest work function
Date: Fri, 30 Jul 2021 07:33:21 -0700 [thread overview]
Message-ID: <CAOQ_QsjFzdjYgYSxNLH=8O84FJB+O8KtH0VnzdQ9HnLZwxwpNQ@mail.gmail.com> (raw)
In-Reply-To: <878s1o2l6j.wl-maz@kernel.org>
Marc,
On Fri, Jul 30, 2021 at 2:41 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Hi Oliver,
>
> On Thu, 29 Jul 2021 23:09:16 +0100,
> Oliver Upton <oupton@google.com> wrote:
> >
> > Clean up handling of checks for pending work by switching to the generic
> > infrastructure to do so.
> >
> > We pick up handling for TIF_NOTIFY_RESUME from this switch, meaning that
> > task work will be correctly handled.
> >
> > Signed-off-by: Oliver Upton <oupton@google.com>
> > ---
> > arch/arm64/kvm/Kconfig | 1 +
> > arch/arm64/kvm/arm.c | 27 ++++++++++++++-------------
> > 2 files changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> > index a4eba0908bfa..8bc1fac5fa26 100644
> > --- a/arch/arm64/kvm/Kconfig
> > +++ b/arch/arm64/kvm/Kconfig
> > @@ -26,6 +26,7 @@ menuconfig KVM
> > select HAVE_KVM_ARCH_TLB_FLUSH_ALL
> > select KVM_MMIO
> > select KVM_GENERIC_DIRTYLOG_READ_PROTECT
> > + select KVM_XFER_TO_GUEST_WORK
> > select SRCU
> > select KVM_VFIO
> > select HAVE_KVM_EVENTFD
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 60d0a546d7fd..9762e2129813 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -6,6 +6,7 @@
> >
> > #include <linux/bug.h>
> > #include <linux/cpu_pm.h>
> > +#include <linux/entry-kvm.h>
> > #include <linux/errno.h>
> > #include <linux/err.h>
> > #include <linux/kvm_host.h>
> > @@ -714,6 +715,13 @@ static bool vcpu_mode_is_bad_32bit(struct kvm_vcpu *vcpu)
> > static_branch_unlikely(&arm64_mismatched_32bit_el0);
> > }
> >
> > +static bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu)
> > +{
> > + return kvm_request_pending(vcpu) ||
> > + need_new_vmid_gen(&vcpu->arch.hw_mmu->vmid) ||
> > + xfer_to_guest_mode_work_pending();
>
> Here's what xfer_to_guest_mode_work_pending() says:
>
> <quote>
> * Has to be invoked with interrupts disabled before the transition to
> * guest mode.
> </quote>
>
> At the point where you call this, we already are in guest mode, at
> least in the KVM sense.
I believe the comment is suggestive of guest mode in the hardware
sense, not KVM's vcpu->mode designation. I got this from
arch/x86/kvm/x86.c:vcpu_enter_guest() to infer the author's
intentions.
>
> > +}
> > +
> > /**
> > * kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code
> > * @vcpu: The VCPU pointer
> > @@ -757,7 +765,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> > /*
> > * Check conditions before entering the guest
> > */
> > - cond_resched();
> > + if (__xfer_to_guest_mode_work_pending()) {
> > + ret = xfer_to_guest_mode_handle_work(vcpu);
>
> xfer_to_guest_mode_handle_work() already does the exact equivalent of
> __xfer_to_guest_mode_work_pending(). Why do we need to do it twice?
Right, there's no need to do the check twice.
>
> > + if (!ret)
> > + ret = 1;
> > + }
> >
> > update_vmid(&vcpu->arch.hw_mmu->vmid);
> >
> > @@ -776,16 +788,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> >
> > kvm_vgic_flush_hwstate(vcpu);
> >
> > - /*
> > - * Exit if we have a signal pending so that we can deliver the
> > - * signal to user space.
> > - */
> > - if (signal_pending(current)) {
> > - ret = -EINTR;
> > - run->exit_reason = KVM_EXIT_INTR;
> > - ++vcpu->stat.signal_exits;
> > - }
> > -
> > /*
> > * If we're using a userspace irqchip, then check if we need
> > * to tell a userspace irqchip about timer or PMU level
> > @@ -809,8 +811,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> > */
> > smp_store_mb(vcpu->mode, IN_GUEST_MODE);
> >
> > - if (ret <= 0 || need_new_vmid_gen(&vcpu->arch.hw_mmu->vmid) ||
> > - kvm_request_pending(vcpu)) {
> > + if (ret <= 0 || kvm_vcpu_exit_request(vcpu)) {
>
> If you are doing this, please move the userspace irqchip handling into
> the helper as well, so that we have a single function dealing with
> collecting exit reasons.
Sure thing.
Thanks for the quick review, Marc!
--
Best,
Oliver
next prev parent reply other threads:[~2021-07-30 14:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 22:09 [PATCH v2 0/3] KVM: arm64: Use generic guest entry infrastructure Oliver Upton
2021-07-29 22:09 ` [PATCH v2 1/3] KVM: arm64: Record number of signal exits as a vCPU stat Oliver Upton
2021-07-29 22:09 ` [PATCH v2 2/3] entry: KVM: Allow use of generic KVM entry w/o full generic support Oliver Upton
2021-07-29 22:09 ` [PATCH v2 3/3] KVM: arm64: Use generic KVM xfer to guest work function Oliver Upton
2021-07-30 9:41 ` Marc Zyngier
2021-07-30 14:33 ` Oliver Upton [this message]
2021-07-30 16:56 ` Sean Christopherson
2021-07-30 17:52 ` Oliver Upton
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='CAOQ_QsjFzdjYgYSxNLH=8O84FJB+O8KtH0VnzdQ9HnLZwxwpNQ@mail.gmail.com' \
--to=oupton@google.com \
--cc=Alexandru.Elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=guangyus@google.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pshier@google.com \
--cc=shakeelb@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=will@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).