From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E638C433EF for ; Thu, 30 Sep 2021 21:57:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DD98A61A35 for ; Thu, 30 Sep 2021 21:57:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229589AbhI3V7H (ORCPT ); Thu, 30 Sep 2021 17:59:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229533AbhI3V7G (ORCPT ); Thu, 30 Sep 2021 17:59:06 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3523DC06176A for ; Thu, 30 Sep 2021 14:57:23 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id e15so31105380lfr.10 for ; Thu, 30 Sep 2021 14:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VJrgIZzgtxa6YpK70z/m29SP7Hw5UszTAKK7fc3/DA=; b=A5QE5aV4FIKYCFm4FmQJcVJLo3lzWAM2HM8tjo7vFO3aObQQQ6S1vDpJQNxxmaRfQb NV84RP6IXgMoedcU3jSVFTm7rWCTWZ3jDyux6m+dsVXjQfvMstMsaaywrhjpRc8WIMyC 9VnoFr868cR1XBqTKlANmDLBnmPd9EqeljHG9vP8jv06ft+yU53GPjvX9cr+yQ7jK7Jh 6vrar2o/0bvLjjcXancx3vxwwXyw4j7FjxmniEHSiMqyinpIEajGEjylyZpLzrqBskgp 2KNOzYBGd24afmcU9Y57qwZed6D5lqOJJcVxsrYl0Z1WQkYfFAvKAXivvQUac0HuGbx2 YwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1VJrgIZzgtxa6YpK70z/m29SP7Hw5UszTAKK7fc3/DA=; b=wZcCA834xxPweQKiFTpsZcsKmFQYrrq6ZM2cw1tmio2gSCrj8dMwbi1yoZElo/HC9D 6PsKIZL23vtnGFZgt10g8bnVh3jEq5YSwuy2vxuYhVFpnWTq7dDgv7OltDTtgHs0TNL5 KM1xEB1G9HOw9okDT1S32zB7jnnjaa+woPYbrFSVjYvM6e6Y0IaBF5FCb6Y4w1c6oqAq PcZm4/FCqPa43uqtLZ8rObE5pR1Z7looDx6BBjeIYPR/slaGXr/r2t+VXXBqlF2dpAbP 8viu3AqczIutrH2DM+i/Vo4k4n5bw9y7dC5weN6gcOndZroAxEyaWQCvctz709yuFKKv ngzQ== X-Gm-Message-State: AOAM533mAzLMhIOu3YljZSiBRxCHoJqYwLgLQaV4YdYxhZMGJ8M3DPwx A3DLchi/YiCi6KQNIU8jn3nC1YLvsH7qu4XqMx6mpw== X-Google-Smtp-Source: ABdhPJwNjZ1Ft7Rzgz1bsFFoRB4MAZdYHAhGAclXUZdIGmyqv+o7vcKq3MEtf03pMU0UI0S/+P5WJEKkm/8e6nprZTQ= X-Received: by 2002:a2e:719:: with SMTP id 25mr8749326ljh.251.1633039041032; Thu, 30 Sep 2021 14:57:21 -0700 (PDT) MIME-Version: 1.0 References: <20210923191610.3814698-1-oupton@google.com> <20210923191610.3814698-6-oupton@google.com> <878rzetk0o.wl-maz@kernel.org> In-Reply-To: From: Oliver Upton Date: Thu, 30 Sep 2021 14:57:10 -0700 Message-ID: Subject: Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event To: Sean Christopherson Cc: Marc Zyngier , kvm@vger.kernel.org, Peter Shier , kvmarm@lists.cs.columbia.edu Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Sep 30, 2021 at 11:08 AM Sean Christopherson wrote: > > On Thu, Sep 30, 2021, Oliver Upton wrote: > > On Thu, Sep 30, 2021 at 10:09 AM Sean Christopherson wrote: > > > 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. > > Is there an actual use case for letting userspace request WFI behavior? So for the system event exits we say that userspace can ignore them and call KVM_RUN again. Running the guest after the suspend exit should appear to the guest as though it had resumed. Userspace could do something fancy to handle the suspend (save the VM, wait for an implementation defined event) or ask the kernel to do it. To that end, the MP state is needed to tell KVM to WFI instead of starting the guest immediately. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE37FC433EF for ; Thu, 30 Sep 2021 21:57:27 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 35E7361A02 for ; Thu, 30 Sep 2021 21:57:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 35E7361A02 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8745C4B091; Thu, 30 Sep 2021 17:57:26 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+rmj-h+iWbD; Thu, 30 Sep 2021 17:57:25 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 50E004B099; Thu, 30 Sep 2021 17:57:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id F0BEC4083E for ; Thu, 30 Sep 2021 17:57:23 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qipr1yRA6zmK for ; Thu, 30 Sep 2021 17:57:22 -0400 (EDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id AB36240667 for ; Thu, 30 Sep 2021 17:57:22 -0400 (EDT) Received: by mail-lf1-f53.google.com with SMTP id x27so31135693lfu.5 for ; Thu, 30 Sep 2021 14:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VJrgIZzgtxa6YpK70z/m29SP7Hw5UszTAKK7fc3/DA=; b=A5QE5aV4FIKYCFm4FmQJcVJLo3lzWAM2HM8tjo7vFO3aObQQQ6S1vDpJQNxxmaRfQb NV84RP6IXgMoedcU3jSVFTm7rWCTWZ3jDyux6m+dsVXjQfvMstMsaaywrhjpRc8WIMyC 9VnoFr868cR1XBqTKlANmDLBnmPd9EqeljHG9vP8jv06ft+yU53GPjvX9cr+yQ7jK7Jh 6vrar2o/0bvLjjcXancx3vxwwXyw4j7FjxmniEHSiMqyinpIEajGEjylyZpLzrqBskgp 2KNOzYBGd24afmcU9Y57qwZed6D5lqOJJcVxsrYl0Z1WQkYfFAvKAXivvQUac0HuGbx2 YwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1VJrgIZzgtxa6YpK70z/m29SP7Hw5UszTAKK7fc3/DA=; b=IWkqfsWoba2bOKmRBcG5wZ+4xK8xBmka+uS7dBPu5F7bgIpOJ1SUVlx4NZ6TIEERQs S+61+4ko/ax6YLv9OBiYAAp+cNGjm+PLPUqFeOXl4F8gEpAuQ13RRSiFrvgEfHQAyUus rZvlhgAFq/dneihSAvOaAp45GHCEjDHw8Fqerv2MoQAMrfNouSQigABbWG7yvB0zZpVD 7AC+CWqk4PBPALbR92I7ayOrrjU4eNXoZBgqjFuPWTHhB5KheASPS1amFn91QpWanAMu RIDlzs54VfCUXm71Si72NjfCONXeghVZHuBgvaoRr7ORH/m9LRTSyg/pxynm5FoICfiy YWsQ== X-Gm-Message-State: AOAM532SC2AYKJBu7eDFMosuqWk7wnE7t9PvxszQOU5PWqKS6HbM75lA WNBK8iQZg6Y2WgRjRAjgLw72UaLhRtq1duJYfrG8Bw== X-Google-Smtp-Source: ABdhPJwNjZ1Ft7Rzgz1bsFFoRB4MAZdYHAhGAclXUZdIGmyqv+o7vcKq3MEtf03pMU0UI0S/+P5WJEKkm/8e6nprZTQ= X-Received: by 2002:a2e:719:: with SMTP id 25mr8749326ljh.251.1633039041032; Thu, 30 Sep 2021 14:57:21 -0700 (PDT) MIME-Version: 1.0 References: <20210923191610.3814698-1-oupton@google.com> <20210923191610.3814698-6-oupton@google.com> <878rzetk0o.wl-maz@kernel.org> In-Reply-To: From: Oliver Upton Date: Thu, 30 Sep 2021 14:57:10 -0700 Message-ID: Subject: Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event To: Sean Christopherson Cc: Marc Zyngier , Peter Shier , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, Sep 30, 2021 at 11:08 AM Sean Christopherson wrote: > > On Thu, Sep 30, 2021, Oliver Upton wrote: > > On Thu, Sep 30, 2021 at 10:09 AM Sean Christopherson wrote: > > > 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. > > Is there an actual use case for letting userspace request WFI behavior? So for the system event exits we say that userspace can ignore them and call KVM_RUN again. Running the guest after the suspend exit should appear to the guest as though it had resumed. Userspace could do something fancy to handle the suspend (save the VM, wait for an implementation defined event) or ask the kernel to do it. To that end, the MP state is needed to tell KVM to WFI instead of starting the guest immediately. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm