From: Marc Zyngier <maz@kernel.org> To: Sean Christopherson <seanjc@google.com> Cc: Oliver Upton <oupton@google.com>, 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: Fri, 01 Oct 2021 14:57:19 +0100 [thread overview] Message-ID: <87h7e0sv9c.wl-maz@kernel.org> (raw) In-Reply-To: <YVXvM2kw8PDou4qO@google.com> On Thu, 30 Sep 2021 18:09:07 +0100, 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. The architecture doesn't really say (that's one of the many IMPDEF behaviours). However, there are at least some extensions (such as statistical profiling) that do require the PC to be accurately recorded together with the effects of the instructions at that PC. If an implementation was to pre-increment the PC, the corresponding trace would be inaccurate. > 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. +1. It really isn't worth the complexity. Thanks, M. -- Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Sean Christopherson <seanjc@google.com> Cc: 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: Fri, 01 Oct 2021 14:57:19 +0100 [thread overview] Message-ID: <87h7e0sv9c.wl-maz@kernel.org> (raw) In-Reply-To: <YVXvM2kw8PDou4qO@google.com> On Thu, 30 Sep 2021 18:09:07 +0100, 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. The architecture doesn't really say (that's one of the many IMPDEF behaviours). However, there are at least some extensions (such as statistical profiling) that do require the PC to be accurately recorded together with the effects of the instructions at that PC. If an implementation was to pre-increment the PC, the corresponding trace would be inaccurate. > 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. +1. It really isn't worth the complexity. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2021-10-01 13:57 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 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 [this message] 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=87h7e0sv9c.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=oupton@google.com \ --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.