linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).