On Fri, Jul 30, 2021 at 9:56 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Fri, Jul 30, 2021, Oliver Upton wrote:
> >
> > On Fri, Jul 30, 2021 at 2:41 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > >
> > > On Thu, 29 Jul 2021 23:09:16 +0100, Oliver Upton <oupton@xxxxxxxxxx> wrote:
> > > > @@ -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.
>
> Yeah, the comment is referring to hardware guest mode. The intent is to verify
> there is no work to be done before making the expensive world switch. There's
> no meaningful interaction with vcpu->mode, on x86 it's simply more convenient
> from a code perspective to throw it into kvm_vcpu_exit_request().
Yep, the same is true for ARM as well, doing it the way it appears in
this patch allows for the recycling of the block to enable irqs and
preemption.
--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
