Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp170336rwe; Wed, 24 Aug 2022 20:05:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR725Rf/QRr8R37pihnF58c7X6h7OhVL/2V0EHrthEKsH3s+eYS0qcO9PA3wu6o5ylHanV+B X-Received: by 2002:a17:90b:4b8d:b0:1fb:4def:1fc1 with SMTP id lr13-20020a17090b4b8d00b001fb4def1fc1mr2266241pjb.121.1661396753720; Wed, 24 Aug 2022 20:05:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661396753; cv=none; d=google.com; s=arc-20160816; b=tgeX0N9yEsT2+I/g2BBout+jJqPgkB87izNTMCGpi0ocJ/13iSDwRDRhW4F6cumiL2 km4RUmku5BTYIJVoN1rWgzlAFk/e+7Y7txyA0GrzlKl50u24O0KWqSyrDvrqlnpTggzJ OoG8Lwa5gl0TveIDSg7bloXlS5+Pk9SXsFb1oInyuLT6S/3bnEFZ8CPhDDkHOpMhCOST apYcuyJLidgGSDUWv1HU9dhztLyKHDeOGBFEzqnVB26ZQfHS1YtYSXij+45QKfakuoDE Ogo78pZW1qbbz7BW34pmL51myfqdaNBSrK3zV5QIshDhl164Mn+SI9jU3LFBGmXUTsex QCSA== 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=cZ5gzNCrmdm3hLAPODSo3m8ewJ0Yui1XSuajAwlxh4E=; b=d1cttJ8nH5N3/o8XAttpp/Ar/bkqPbEXIbCcdgdnVZ4oyD7kesDvbt4HV6NA8N+vWb AblCkGhhEyp36OtrTpiY7EBjcnHaIacZf4/B3HiBYQj7gear2r3JwYS1tN6sA3jGYPH7 gQSjWg/feLipFKm1tKDhP++6dS3DWkdZsbEHJGiLu7XYmMuY4vRd3XmL/CqVHL5DaYMZ e3C7VGyfEDB/LgblXzORZAUMF2eqYe4q0OuuqjNMWX4H2oUV1FzdZlerC4rvUrWm/BfW +C0n16+hH/o5bA+fQGVuNWnYNf6oKDV7UbZ3a4yizerh8EYdRWBO9yppvaGZiS29Qzyn B2aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JQ4b7CBx; 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 j37-20020a635965000000b0041c7995ecc6si19028021pgm.87.2022.08.24.20.05.40; Wed, 24 Aug 2022 20:05:53 -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=JQ4b7CBx; 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 S231722AbiHYCvx (ORCPT + 99 others); Wed, 24 Aug 2022 22:51:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230104AbiHYCvw (ORCPT ); Wed, 24 Aug 2022 22:51:52 -0400 Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 298D89C8FF for ; Wed, 24 Aug 2022 19:51:51 -0700 (PDT) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-11c9af8dd3eso22904216fac.10 for ; Wed, 24 Aug 2022 19:51:51 -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=cZ5gzNCrmdm3hLAPODSo3m8ewJ0Yui1XSuajAwlxh4E=; b=JQ4b7CBxWO7nskQf5m+6YvtLrJeNJcHsCNDT7BpIszut0+dYBhEt+GVITxHEMQyCGS a1IsOxh/8/92ZfwljodwkTWc4Nv+tnPKeMdGHX6M8uqQuf5950C03dhiyRVoWrSY6kn+ Tdb1qY/XexGGue2BHOyvHrYYM4x3AyQ+THW4IL6pnIIktKXE7u9E7pDYguV/Sr89OoRj aIk/b3HE5dH+DkcSgKKpM1InPEpSXnSPOPpTOlOJJ00i22Cq/Je9rJs2UbhAKYs0kU8j h9SEe31FmmJ2jOvaa4z+ZpVOSUGzo7kSgUxwiquPw99yLyzHtkcUCPEudegUNbt8cnHw cluQ== 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=cZ5gzNCrmdm3hLAPODSo3m8ewJ0Yui1XSuajAwlxh4E=; b=ym9LPU7C1kbtf58qhB8DOup5MIOlFKvLP7twxntAd5pEbLsjnhDwbaU8gPZ7PzPPV1 9+ZTMG/Nhn/zZ7sJDnzZf6DybPcOZ0VGB/O4mtiJxgS6fGs5lYK4cnsmMH71BHuTjPcN DfWtIwPMXIK5kjI/9DPazySJMUaM0WC81cVc96zmLKzKZXva5Dg+XLI65zeyxxONQ2Mo HHbvYD+mrVzcA4xE9LQ+/Dfd44dmZEoJTb/uq1XQcumlwQhDjjSsSS1ccV6+Zyj+2yMK ocgpHlZfINgs1JvpKbFDKX7R0IG4CBGZhHNVLsHWOJIqN0S6cEeGl73LmsdGe913J0rD hymA== X-Gm-Message-State: ACgBeo0tAFSO/ZTXhhX7KwBXgMELZsb6Wnoy3E3HBMZDMpcmsdcCS42i JrgsrX5UoaUT0v8Ejyg1VEX9Rb9r3sgmavBdKHBd3Q== X-Received: by 2002:a05:6870:c596:b0:101:6409:ae62 with SMTP id ba22-20020a056870c59600b001016409ae62mr5053901oab.112.1661395910321; Wed, 24 Aug 2022 19:51:50 -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: Jim Mattson Date: Wed, 24 Aug 2022 19:51:39 -0700 Message-ID: Subject: Re: [PATCH 1/5] KVM: x86: Get vmcs12 pages before checking pending interrupts To: Sean Christopherson Cc: Maxim Levitsky , Mingwei Zhang , 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 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?