From: Oliver Upton <oupton@google.com> To: Sean Christopherson <seanjc@google.com> Cc: Marc Zyngier <maz@kernel.org>, kvm@vger.kernel.org, Peter Shier <pshier@google.com>, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event Date: Thu, 30 Sep 2021 10:32:49 -0700 [thread overview] Message-ID: <CAOQ_QsjXs8sF+QY0NrSVBvO4xump7CttBU3et6V3O_hNYmCSig@mail.gmail.com> (raw) In-Reply-To: <YVXvM2kw8PDou4qO@google.com> On Thu, Sep 30, 2021 at 10:09 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Sep 30, 2021, Marc Zyngier wrote: > > On Thu, 23 Sep 2021 20:16:04 +0100, Oliver Upton <oupton@google.com> wrote: > > > @@ -681,6 +687,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu) > > > if (kvm_check_request(KVM_REQ_SLEEP, vcpu)) > > > kvm_vcpu_sleep(vcpu); > > > > > > + if (kvm_check_request(KVM_REQ_SUSPEND, vcpu)) > > > + kvm_vcpu_suspend(vcpu); > > > + > > ... > > > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > > > index 275a27368a04..5e5ef9ff4fba 100644 > > > --- a/arch/arm64/kvm/handle_exit.c > > > +++ b/arch/arm64/kvm/handle_exit.c > > > @@ -95,8 +95,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu) > > > } else { > > > trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false); > > > vcpu->stat.wfi_exit_stat++; > > > - kvm_vcpu_block(vcpu); > > > - kvm_clear_request(KVM_REQ_UNHALT, vcpu); > > > + kvm_make_request(KVM_REQ_SUSPEND, vcpu); > > > } > > > > > > kvm_incr_pc(vcpu); > > > > This is a change in behaviour. At the point where the blocking > > happens, PC will have already been incremented. I'd rather you don't > > do that. Instead, make the helper available and call into it directly, > > preserving the current semantics. > > Is there architectural behavior that KVM can emulate? E.g. if you were to probe a > physical CPU while it's waiting, would you observe the pre-WFI PC, or the post-WFI > PC? Following arch behavior would be ideal because it eliminates subjectivity. > Regardless of the architectural behavior, changing KVM's behavior should be > done explicitly in a separate patch. > > Irrespective of PC behavior, I would caution against using a request for handling > WFI. Deferring the WFI opens up the possibility for all sorts of ordering > oddities, e.g. if KVM exits to userspace between here and check_vcpu_requests(), > then KVM can end up with a "spurious" pending KVM_REQ_SUSPEND if maniupaltes vCPU > state. I highly doubt that userspace VMMs would actually do that, as it would > basically require a signal from userspace, but it's not impossible, and at the > very least the pending request is yet another thing to worry about in the future. > > Unlike PSCI power-off, WFI isn't cross-vCPU, thus there's no hard requirement > for using a request. And KVM_REQ_SLEEP also has an additional guard in that it > doesn't enter rcuwait if power_off (or pause) was cleared after the request was > made, e.g. if userspace stuffed vCPU state and set the vCPU RUNNABLE. Yeah, I don't think the punt is necessary for anything but the case where userspace sets the MP state to request WFI behavior. A helper method amongst all WFI cases is sufficient, and using the deferral for everything is a change in behavior. > > It is also likely to clash with Sean's kvm_vcpu_block() rework, but we > > can work around that. > > Ya. Oliver, can you Cc me on future patches? I'll try to keep my eyeballs on this > series. Sure thing :)
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oupton@google.com> To: Sean Christopherson <seanjc@google.com> Cc: Marc Zyngier <maz@kernel.org>, Peter Shier <pshier@google.com>, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Subject: Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event Date: Thu, 30 Sep 2021 10:32:49 -0700 [thread overview] Message-ID: <CAOQ_QsjXs8sF+QY0NrSVBvO4xump7CttBU3et6V3O_hNYmCSig@mail.gmail.com> (raw) In-Reply-To: <YVXvM2kw8PDou4qO@google.com> On Thu, Sep 30, 2021 at 10:09 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Sep 30, 2021, Marc Zyngier wrote: > > On Thu, 23 Sep 2021 20:16:04 +0100, Oliver Upton <oupton@google.com> wrote: > > > @@ -681,6 +687,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu) > > > if (kvm_check_request(KVM_REQ_SLEEP, vcpu)) > > > kvm_vcpu_sleep(vcpu); > > > > > > + if (kvm_check_request(KVM_REQ_SUSPEND, vcpu)) > > > + kvm_vcpu_suspend(vcpu); > > > + > > ... > > > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > > > index 275a27368a04..5e5ef9ff4fba 100644 > > > --- a/arch/arm64/kvm/handle_exit.c > > > +++ b/arch/arm64/kvm/handle_exit.c > > > @@ -95,8 +95,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu) > > > } else { > > > trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false); > > > vcpu->stat.wfi_exit_stat++; > > > - kvm_vcpu_block(vcpu); > > > - kvm_clear_request(KVM_REQ_UNHALT, vcpu); > > > + kvm_make_request(KVM_REQ_SUSPEND, vcpu); > > > } > > > > > > kvm_incr_pc(vcpu); > > > > This is a change in behaviour. At the point where the blocking > > happens, PC will have already been incremented. I'd rather you don't > > do that. Instead, make the helper available and call into it directly, > > preserving the current semantics. > > Is there architectural behavior that KVM can emulate? E.g. if you were to probe a > physical CPU while it's waiting, would you observe the pre-WFI PC, or the post-WFI > PC? Following arch behavior would be ideal because it eliminates subjectivity. > Regardless of the architectural behavior, changing KVM's behavior should be > done explicitly in a separate patch. > > Irrespective of PC behavior, I would caution against using a request for handling > WFI. Deferring the WFI opens up the possibility for all sorts of ordering > oddities, e.g. if KVM exits to userspace between here and check_vcpu_requests(), > then KVM can end up with a "spurious" pending KVM_REQ_SUSPEND if maniupaltes vCPU > state. I highly doubt that userspace VMMs would actually do that, as it would > basically require a signal from userspace, but it's not impossible, and at the > very least the pending request is yet another thing to worry about in the future. > > Unlike PSCI power-off, WFI isn't cross-vCPU, thus there's no hard requirement > for using a request. And KVM_REQ_SLEEP also has an additional guard in that it > doesn't enter rcuwait if power_off (or pause) was cleared after the request was > made, e.g. if userspace stuffed vCPU state and set the vCPU RUNNABLE. Yeah, I don't think the punt is necessary for anything but the case where userspace sets the MP state to request WFI behavior. A helper method amongst all WFI cases is sufficient, and using the deferral for everything is a change in behavior. > > It is also likely to clash with Sean's kvm_vcpu_block() rework, but we > > can work around that. > > Ya. Oliver, can you Cc me on future patches? I'll try to keep my eyeballs on this > series. Sure thing :) _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2021-09-30 17:33 UTC|newest] Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-23 19:15 [PATCH v2 00/11] KVM: arm64: Implement PSCI SYSTEM_SUSPEND support Oliver Upton 2021-09-23 19:15 ` Oliver Upton 2021-09-23 19:16 ` [PATCH v2 01/11] KVM: arm64: Drop unused vcpu param to kvm_psci_valid_affinity() Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-01 3:50 ` Reiji Watanabe 2021-10-01 3:50 ` Reiji Watanabe 2021-10-05 13:22 ` Andrew Jones 2021-10-05 13:22 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 02/11] KVM: arm64: Clean up SMC64 PSCI filtering for AArch32 guests Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-01 3:56 ` Reiji Watanabe 2021-10-01 3:56 ` Reiji Watanabe 2021-10-05 13:23 ` Andrew Jones 2021-10-05 13:23 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 03/11] KVM: arm64: Encapsulate reset request logic in a helper function Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-01 6:04 ` Reiji Watanabe 2021-10-01 6:04 ` Reiji Watanabe 2021-10-01 16:10 ` Oliver Upton 2021-10-01 16:10 ` Oliver Upton 2021-10-05 13:33 ` Andrew Jones 2021-10-05 13:33 ` Andrew Jones 2021-10-05 15:05 ` Oliver Upton 2021-10-05 15:05 ` Oliver Upton 2021-10-05 19:01 ` Andrew Jones 2021-10-05 19:01 ` Andrew Jones 2021-10-13 4:48 ` Reiji Watanabe 2021-10-13 4:48 ` Reiji Watanabe 2021-10-05 13:35 ` Andrew Jones 2021-10-05 13:35 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 04/11] KVM: arm64: Rename the KVM_REQ_SLEEP handler Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-05 13:34 ` Andrew Jones 2021-10-05 13:34 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-09-30 10:50 ` Marc Zyngier 2021-09-30 10:50 ` Marc Zyngier 2021-09-30 17:09 ` Sean Christopherson 2021-09-30 17:09 ` Sean Christopherson 2021-09-30 17:32 ` Oliver Upton [this message] 2021-09-30 17:32 ` Oliver Upton 2021-09-30 18:08 ` Sean Christopherson 2021-09-30 18:08 ` Sean Christopherson 2021-09-30 21:57 ` Oliver Upton 2021-09-30 21:57 ` Oliver Upton 2021-10-01 13:57 ` Marc Zyngier 2021-10-01 13:57 ` Marc Zyngier 2021-09-23 19:16 ` [PATCH v2 06/11] KVM: arm64: Add support for SYSTEM_SUSPEND PSCI call Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-09-30 12:29 ` Marc Zyngier 2021-09-30 12:29 ` Marc Zyngier 2021-09-30 17:19 ` Sean Christopherson 2021-09-30 17:19 ` Sean Christopherson 2021-09-30 17:35 ` Oliver Upton 2021-09-30 17:35 ` Oliver Upton 2021-09-30 17:40 ` Oliver Upton 2021-09-30 17:40 ` Oliver Upton 2021-10-01 14:02 ` Marc Zyngier 2021-10-01 14:02 ` Marc Zyngier 2021-10-05 16:02 ` Oliver Upton 2021-10-05 16:02 ` Oliver Upton 2021-09-23 19:16 ` [PATCH v2 07/11] selftests: KVM: Rename psci_cpu_on_test to psci_test Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-05 13:36 ` Andrew Jones 2021-10-05 13:36 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 08/11] selftests: KVM: Create helper for making SMCCC calls Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-05 13:39 ` Andrew Jones 2021-10-05 13:39 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 09/11] selftests: KVM: Use KVM_SET_MP_STATE to power off vCPU in psci_test Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-09-23 19:16 ` [PATCH v2 10/11] selftests: KVM: Refactor psci_test to make it amenable to new tests Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-05 13:45 ` Andrew Jones 2021-10-05 13:45 ` Andrew Jones 2021-10-05 14:54 ` Oliver Upton 2021-10-05 14:54 ` Oliver Upton 2021-10-05 19:05 ` Andrew Jones 2021-10-05 19:05 ` Andrew Jones 2021-09-23 19:16 ` [PATCH v2 11/11] selftests: KVM: Test SYSTEM_SUSPEND PSCI call Oliver Upton 2021-09-23 19:16 ` Oliver Upton 2021-10-05 13:49 ` Andrew Jones 2021-10-05 13:49 ` Andrew Jones 2021-10-05 15:07 ` Oliver Upton 2021-10-05 15:07 ` Oliver Upton 2021-09-23 20:15 ` [PATCH v2 00/11] KVM: arm64: Implement PSCI SYSTEM_SUSPEND support Oliver Upton 2021-09-23 20:15 ` 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_QsjXs8sF+QY0NrSVBvO4xump7CttBU3et6V3O_hNYmCSig@mail.gmail.com \ --to=oupton@google.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=maz@kernel.org \ --cc=pshier@google.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: linkBe 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.