Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp879710rwe; Thu, 25 Aug 2022 10:43:48 -0700 (PDT) X-Google-Smtp-Source: AA6agR54St/f4yMLoSsAZqopZDkqPdTXr5BPvQV9ckQvu6qh3KUfOsG55FyvsaG44A6hXO8tk14P X-Received: by 2002:a63:e242:0:b0:421:9053:8923 with SMTP id y2-20020a63e242000000b0042190538923mr158518pgj.283.1661449427642; Thu, 25 Aug 2022 10:43:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661449427; cv=none; d=google.com; s=arc-20160816; b=YKi4t0glrUBtfXM5RdX8BHipUx5NMdzQ8zUYNj8H5jqt1zGTcSnQWs83eq4cCbLGi2 /JoVFEJN3Dg67dA1gV2yEI5NMJ2GQ4RUqSrSk6p/0Lq4rB38S+Y56YgvNCHQ1CWUkAUS d3cqXxWUuY7oOPFueM8CrZd7abSfyWKs5yFhJUzl56TzE205T8YZc9KxskqNIyr4D/uM snDWqpr2SfLUTInYjCA0KMDAm+yG0PWtiqyv/F70m7RxFEuXXHgaefZ/jAb6MFOsUHBa AucFEcjyvXjGPtJZI8/phv1AQsyCXAmUi5KTxL3uSYJPSkbiHbToqZ6j/O5nnL24gPf0 1mKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kXvA442rNX297fyG/Fyw0vfNRXroRxF/pdkw6Qxv8UE=; b=C38ptHHKnzH86WQt2nUs8ko0Ne0aVdA+ZO9hPCHzfhfcnxeRDuH/VzUPIea1TziTdS /OlC0s26/HZHn24GoUdrChRy+Tzo4mlQs66U86ZjdyvwCCycyc3pvtuiGoxjvcdxeJc0 UVru00ufpbdipf2Txjt4gLlj5DuubGbWEJdEfgiLvkkDdUHBD6CWjCdrWe9iRkLB67sw y9CRbv98UFsl7Nx0NsNHkOHfbEYvO8HeFCOvYUcS2YZidvjXyzy0GMmyawR+UEfebCrX VAlm7cXd9NzXFpLIM50MThQ5sLmvGeILijMGPdLTx7KKqeTA6s9nNc2LPbl/7caimGeL wtKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ToZvmVtN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d4-20020a633604000000b0041dd0c35c54si19660027pga.47.2022.08.25.10.43.34; Thu, 25 Aug 2022 10:43:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=ToZvmVtN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240732AbiHYRQo (ORCPT + 99 others); Thu, 25 Aug 2022 13:16:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239959AbiHYRQl (ORCPT ); Thu, 25 Aug 2022 13:16:41 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 681B3A4B1F for ; Thu, 25 Aug 2022 10:16:39 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id hf17so2346019pjb.3 for ; Thu, 25 Aug 2022 10:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=kXvA442rNX297fyG/Fyw0vfNRXroRxF/pdkw6Qxv8UE=; b=ToZvmVtN0p6cjcXv9Y3Nir8/tTLpU8oAKTTXY8BnakyanfxEZ8x3PRjpKKZqm8fS0y NXX5W+9ZWMqepi4v8sFZIiHT9mASAYrThJl/YCihJTrc9FUpoV9/zyiUdsxJYZXcrAfy BKSDQ6WrDpfiWoUynYxmgSOp7dQjmRKQNjhawEk6bnFddnrwziL7gNIKWBuhFqojnKYu +gOh3T9opmBkHTzdTxjwLaxAkhhGY7WdH61OmSe/Ku59drVzSysnTes4IuJS+gbLo9uy lnYYvDBrQMmoFtb9PwWTE2MCvHaKWctNNlKrmlIBkl03TgohWXCiUy/fY3w3a4gWQEZE gOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=kXvA442rNX297fyG/Fyw0vfNRXroRxF/pdkw6Qxv8UE=; b=mfEIZpcVz9oaZyW7pvUl8DHHCiBescof3KZTfa6f3ijMlfbew7OtIiYQ1fiiMxdM23 eBsx9+pCmXGKQ1aa/QguUCNFR6tVMMNc6FXI91C9/W4C+Fr4hvSqegJgTxDzXgeridre kZJtF295hEt2bDtFJXFLUZFUyHboPQhFy3B48aApNcmyirxCb4kcbaq9vRxWJ+KX+VEs cMAFNnGlSqtunDVf7Ql0/vsoLlzhDuGg1VAURFtWGVjCoy0U7u2sP0RJRIEJ/stOq8yi tiFEfbhsxC/Wtuc6CODI/7xBEaYEenEpDot3wCQi2nUGklz0iWaXQQXgZaHeEtGcMC85 1ntQ== X-Gm-Message-State: ACgBeo2w8RoOBnOZOw3BZUCRN31coiwfwY+0Wr5k+Ov3p6Q9b0//wydF pPyWuptCjpUNRgZApBayQwJ55UCoNfEBJQJKm7L39Q== X-Received: by 2002:a17:903:41d1:b0:172:ee09:e89e with SMTP id u17-20020a17090341d100b00172ee09e89emr3200ple.61.1661447798596; Thu, 25 Aug 2022 10:16:38 -0700 (PDT) MIME-Version: 1.0 References: <20220802230718.1891356-1-mizhang@google.com> <20220802230718.1891356-2-mizhang@google.com> <17505e309d02cf5a96e33f75ccdd6437a8c79222.camel@redhat.com> In-Reply-To: From: Mingwei Zhang Date: Thu, 25 Aug 2022 10:16:27 -0700 Message-ID: Subject: Re: [PATCH 1/5] KVM: x86: Get vmcs12 pages before checking pending interrupts To: Sean Christopherson Cc: Jim Mattson , Maxim Levitsky , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm , LKML , Oliver Upton Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2022 at 7:41 AM Sean Christopherson wrote: > > On Wed, Aug 24, 2022, Jim Mattson wrote: > > On Wed, Aug 24, 2022 at 5:11 PM Sean Christopherson wrote: > > > > > @google folks, what would it take for us to mark KVM_REQ_GET_NESTED_STATE_PAGES > > > as deprecated in upstream and stop accepting patches/fixes? IIUC, when we eventually > > > move to userfaultfd, all this goes away, i.e. we do want to ditch this at some point. > > > > Userfaultfd is a red herring. There were two reasons that we needed > > this when nested live migration was implemented: > > 1) our netlink socket mechanism for funneling remote page requests to > > a userspace listener was broken. > > 2) we were not necessarily prepared to deal with remote page requests > > during VM setup. > > > > (1) has long since been fixed. Though our preference is to exit from > > KVM_RUN and get the vCPU thread to request the remote page itself, we > > are now capable of queuing a remote page request with a separate > > listener thread and blocking in the kernel until the page is received. > > I believe that mechanism is functionally equivalent to userfaultfd, > > though not as elegant. > > I don't know about (2). I'm not sure when the listener thread is set > > up, relative to all of the other setup steps. Eliminating > > KVM_REQ_GET_NESTED_STATE_PAGES means that userspace must be prepared > > to fetch a remote page by the first call to KVM_SET_NESTED_STATE. The > > same is true when using userfaultfd. > > > > These new ordering constraints represent a UAPI breakage, but we don't > > seem to be as concerned about that as we once were. Maybe that's a > > good thing. Can we get rid of all of the superseded ioctls, like > > KVM_SET_CPUID, while we're at it? > > I view KVM_REQ_GET_NESTED_STATE_PAGES as a special case. We are likely the only > users, we can (eventually) wean ourselves off the feature, and we can carry > internal patches (which we are obviously already carrying) until we transition > away. And unlike KVM_SET_CPUID and other ancient ioctls() that are largely > forgotten, this feature is likely to be a maintenance burden as long as it exists. KVM_REQ_GET_NESTED_STATE_PAGES has been uniformly used in KVM_SET_NESTED_STATE ioctl in VMX (including eVMCS) and SVM, it is basically a two-step setting up of a nested state mechanism. We can change that, but this may have side effects and I think this usage case has nothing to do with demand paging. I noticed that nested_vmx_enter_non_root_mode() is called in KVM_SET_NESTED_STATE in VMX, while in SVM implementation, it is simply just a kvm_make_request(KVM_REQ_GET_NESTED_STATE_PAGES, vcpu); hmm... so is the nested_vmx_enter_non_root_mode() call in vmx KVM_SET_NESTED_STATE ioctl() still necessary? I am thinking that because the same function is called again in nested_vmx_run(). Thanks. -Mingwei