Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5252826rwb; Tue, 6 Sep 2022 22:55:48 -0700 (PDT) X-Google-Smtp-Source: AA6agR4Exfh/ZLiN9XB8kSlPk5Fi211h8BqjnMn9cn8ID3RYy7J1c1hDLlzrAE9WaeqDkjgXg8Ed X-Received: by 2002:a17:907:8a22:b0:73d:8a12:2d1c with SMTP id sc34-20020a1709078a2200b0073d8a122d1cmr1193908ejc.154.1662530148209; Tue, 06 Sep 2022 22:55:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662530148; cv=none; d=google.com; s=arc-20160816; b=uexjHDCcs2cVgUcoc+AmG7LbVJflC919BCtMVeed0JeZHCDGVmuAwiYuZoGTFopGXy kW3pnmUCxTdQDL/6sBfrhU0k2UK2kYip2x2CgdnihBgTnUeKWnWLN4wrJNXGDj60X8hJ E6Uybxk6tMg65fbzAAwR6Kr5mG3lhB5T1/6TXmRBOk3HF+Sav9fZCkEAJm7MjrusUch6 62HY6YRQaPmHjjFATW3HLzvrn+ADTFAaQFV2n9XnSvTGdwN0ohkOQLg03hRFsn7bd7d5 bBm7Vs98aR9Hf7PA2b9rTB3sUrx1A4XioaYjyHYh7I5OYvC40AtkEitNndL9ZPC3iHg2 AE4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=A0j0PNYBJIbXIuXxR5aWCTJEQtLdmyL8sLeX5Hkv6DA=; b=D4NSaMA+7aKcWEZXvjUm9eZ770pGx2ullcv7K33QrHIOFHLY0lDI0xiAgV6/5dFjsS w3d+VpP0dS/YQzXJ9+JQYKRupwAce6rM6muTNyDxoXr9MNwof1PFithyAEn7TjxGdzjj EeOnSdZw4gw99KNOm7+ovrcQ9ji3hUC9zoUBQD/I0Ch7HUlv+zMnyP1BSnSy0iKLbYpc 8uHOWa/ZeFBqrhpdWZq33gwumfdQf5dkE/I3obXtezaXNrrMGB4wFJT4XB8xiIoun8p/ U5mOi8zeujg9BLX5YFZyn0QS6Px2nZJ4etMsl05IhZHCexZnR/C3nl+qlaXJFvhDVdqZ 4z2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=AMDxu4eO; 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=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dd20-20020a1709069b9400b0077086aa2b0fsi267975ejc.457.2022.09.06.22.55.22; Tue, 06 Sep 2022 22:55:48 -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=@intel.com header.s=Intel header.b=AMDxu4eO; 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=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229732AbiIGFfa (ORCPT + 99 others); Wed, 7 Sep 2022 01:35:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbiIGFf1 (ORCPT ); Wed, 7 Sep 2022 01:35:27 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 298124B49D; Tue, 6 Sep 2022 22:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662528926; x=1694064926; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=s/ws2IVLLDd2yoBtML6C/t5SDZcAcQIo3h0hl+fCkPk=; b=AMDxu4eOgCDPC3ZRPKuvt0Pmx+XVEdlXHEQ/UtPxcixdaYSnbpNTo3B8 4nNHhPgGLUt/+hLGxEBsKaTq8HSa3QRX5mGdj2q9nrY15TXpRUUCImA3W 5GNzqg/fuOTH3BAh9+C43/qKoLi68aRD0pGBvsxiaFZ64hwdc0Xb/3p4S mRefITf0v1wqziI/x2keKun5J8WT4J5lt575JKVOxvAkOive7z0N+E1E+ YccovW4k10OI3hPmIqxFlO8gkn3AVKVQ6IigFG3Eg2bSbUQEYsxvh3AFa XBIkyWdOpEp0tDZFnjQoVVNe+80oHtpQwmTZpb40e7z+1OMe813+6RfMl g==; X-IronPort-AV: E=McAfee;i="6500,9779,10462"; a="277177789" X-IronPort-AV: E=Sophos;i="5.93,295,1654585200"; d="scan'208";a="277177789" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2022 22:35:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,295,1654585200"; d="scan'208";a="676020466" Received: from yy-desk-7060.sh.intel.com (HELO localhost) ([10.239.159.76]) by fmsmga008.fm.intel.com with ESMTP; 06 Sep 2022 22:35:24 -0700 Date: Wed, 7 Sep 2022 13:35:23 +0800 From: Yuan Yao To: Mingwei Zhang Cc: Sean Christopherson , Paolo Bonzini , kvm , LKML , Maxim Levitsky , Vitaly Kuznetsov , Oliver Upton , Jim Mattson Subject: Re: [PATCH v2 1/4] KVM: x86: move the event handling of KVM_REQ_GET_VMCS12_PAGES into a common function Message-ID: <20220907053523.qb7qsbqfgcg2d2vx@yy-desk-7060> References: <20220828222544.1964917-1-mizhang@google.com> <20220828222544.1964917-2-mizhang@google.com> <20220907025042.hvfww56wskwhsjwk@yy-desk-7060> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE 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 Tue, Sep 06, 2022 at 09:26:33PM -0700, Mingwei Zhang wrote: > > > @@ -10700,6 +10706,12 @@ static int vcpu_run(struct kvm_vcpu *vcpu) > > > if (kvm_cpu_has_pending_timer(vcpu)) > > > kvm_inject_pending_timer_irqs(vcpu); > > > > > > + if (vcpu->arch.nested_get_pages_pending) { > > > + r = kvm_get_nested_state_pages(vcpu); > > > + if (r <= 0) > > > + break; > > > + } > > > + > > > > Will this leads to skip the get_nested_state_pages for L2 first time > > vmentry in every L2 running iteration ? Because with above changes > > KVM_REQ_GET_NESTED_STATE_PAGES is not set in > > nested_vmx_enter_non_root_mode() and > > vcpu->arch.nested_get_pages_pending is not checked in > > vcpu_enter_guest(). > > > Good catch. I think the diff won't work when vcpu is runnable. It only > tries to catch the vcpu block case. Even for the vcpu block case, the > check of KVM_REQ_UNBLOCK is way too late. Ah, kvm_vcpu_check_block() > is called by kvm_vcpu_block() which is called by vcpu_block(). The > warning is triggered at the very beginning of vcpu_block(), i.e., > within kvm_arch_vcpu_runnable(). So, please ignore the trace in my > previous email. > > In addition, my minor push back for that is > vcpu->arch.nested_get_pages_pending seems to be another > KVM_REQ_GET_NESTED_STATE_PAGES. Yeah, but in concept level it's not a REQ mask lives in the vcpu->requests which can be cached by e.g. kvm_request_pending(). It's necessary to check vcpu->arch.nested_get_pages_pending in vcpu_enter_guest() if Sean's idea is to replace KVM_REQ_GET_NESTED_STATE_PAGES with nested_get_pages_pending. > > Thanks. > -Mingwei > > > -Mingwei