Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp709583rwe; Thu, 25 Aug 2022 07:59:04 -0700 (PDT) X-Google-Smtp-Source: AA6agR5DNmRvP0zHsO89ZtR0hOU2Utbbs+UvdxDaVHyry0TOMjG9XKnMvt1EF6ALv5xvbcHgHqEZ X-Received: by 2002:a17:907:2894:b0:73d:8d03:ff11 with SMTP id em20-20020a170907289400b0073d8d03ff11mr2774439ejc.307.1661439544049; Thu, 25 Aug 2022 07:59:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661439544; cv=none; d=google.com; s=arc-20160816; b=0Yu2AaCR4WXAqyYmcE3nUSTae6qez8Bb3VgZuHj5xlVf8D94ukujLiuI4w+gUEHNmd 1NRjgjM17w07MXNdg5CvcVV8B71j8dmzbdSvrVWE6GFUJ/I1urAP5zcKCPoHLER1BKkq K+Tks4iOFpmDwuYDAj6SW1LaKRCIR7GrmNbzDDsR+iKM97TAZ2kvm5xhC4I3YqG0sXGy +nhuVY/H29eDwJe/kcDq9JtBvuAvZLYPcKethz5z/IxJ7sd+zfqXaIXVnbLBDnKeVaeT MXGwAHDr1Bwd0cml3T83sw9+0LC+VoJZdzy0NyWPk/dXramXqMMKlSK/ZX/pHuoHbG0g 46Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ZbQl5zmcQJYLrJInunPEiMFIWd9Xor7csOXerZPZEys=; b=TotSrnzCb7uuHJNiAn5ZzB7kzofl/qyFQ0zIJUV08BUIKsOwIGqud9Y5AzcUieqqhf Taa3EQny3GvHToDFXrwlGEgXIb45sIQAW3z+N28EIWOvwlsiM47D/DaYYAMh0oq7FDCK iJWK6oCFCSkCkp1QsLRqr1+bP37aFAE9HvIDnak8zrcqQEbdQtURt6+ZtcniRPsH3Of0 cUc2N17+/xfFoRaJQEsAs7S5hm05E59vFN8TZ08FLVUUK+ZkB7Bu8bsR5q6GylNe4Wvm vt4lHxzNKehM2NV3BgZhgM4VP9XVXMu1KSFt3Ff5ryPsg6AWdZIqtIXftHiONZ1bjwlr /uow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Y5yVxnEf; 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 dd17-20020a1709069b9100b0072f40d666d6si4070801ejc.602.2022.08.25.07.58.37; Thu, 25 Aug 2022 07:59:04 -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=Y5yVxnEf; 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 S242578AbiHYOnI (ORCPT + 99 others); Thu, 25 Aug 2022 10:43:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242584AbiHYOmn (ORCPT ); Thu, 25 Aug 2022 10:42:43 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38635B81F5 for ; Thu, 25 Aug 2022 07:41:04 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id 67so11791969pfv.2 for ; Thu, 25 Aug 2022 07:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=ZbQl5zmcQJYLrJInunPEiMFIWd9Xor7csOXerZPZEys=; b=Y5yVxnEfhqYg2VzNtwH3XMv1GhyAfwGAK9sKYjHECt3tGSTlM8/jHpaJ/RPHG9QSz0 to4y3mp5uLhUUXaLCxd/nkp+Hmjce8XXsze0vkJhV0dwKK9DUt7jHaQCYY27ATKLgS7A jtaiS6QU0ypyCmP0meBxTp6VRT9g6u5PDKGQXpZKgwkpeX5B07/FpfLyetM8EhKI0TdP 4fHkOuv7ceFmC/Wrbxbmn17N5OPQETlK4iaNPXONDzpmbLTfwtPlwdVHQcxmntM0VBmC 1pnrH7IlaJ0TqdXPjM/NsN5epj8IIt2UcdiQ0kJc+B9yezkUPKD7RoX6wNmjPMjFgEld trXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=ZbQl5zmcQJYLrJInunPEiMFIWd9Xor7csOXerZPZEys=; b=VEl9yxaTGArzka4xijPXfonaRLPXivqPqGnCWkUBm4Rl8BrRNWjUDAx8bKlYHRfyuu J8nyaE9Y8Yvmc6YGrGAepeVZAzJmCdc2WCbK00mPvnr/35TCzvcTYIOhLT5ukuYAAbKw RJNMa4jprRIMZxud8LrHEr64H01foHINEx8ngVaTEtgw9/CcfAykN/FbDjSkh4RANZJA DTmb8XNcZim+osdz7YL5jaIe/Sz72ZHzkhKUdWj01v0Ka5mO1al84tP+ZM1rbhVdgBQr fiCsdJhxJlqrh9HOqV8IQCZsrJvWmsoyj7qEgeTTMtmNlUQWl9fpFd9HOgataa3zAPaQ Vgyg== X-Gm-Message-State: ACgBeo0YFV18YLWCUjqnI9chkRhGaDRr3ZcQ7lvz9JwyYPnpaZMiRNGL umjv3dLamHaRABOGy+yt3Tkyvw== X-Received: by 2002:a63:5c42:0:b0:42b:452f:8e66 with SMTP id n2-20020a635c42000000b0042b452f8e66mr3578134pgm.323.1661438463043; Thu, 25 Aug 2022 07:41:03 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id v68-20020a626147000000b0052e6c058bccsm13273939pfb.61.2022.08.25.07.41.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 07:41:02 -0700 (PDT) Date: Thu, 25 Aug 2022 14:40:58 +0000 From: Sean Christopherson To: Jim Mattson Cc: Maxim Levitsky , Mingwei Zhang , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , kvm , LKML , Oliver Upton Subject: Re: [PATCH 1/5] KVM: x86: Get vmcs12 pages before checking pending interrupts Message-ID: References: <20220802230718.1891356-1-mizhang@google.com> <20220802230718.1891356-2-mizhang@google.com> <17505e309d02cf5a96e33f75ccdd6437a8c79222.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-14.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,FSL_HELO_FAKE,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=no 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 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.