Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1485276pxb; Wed, 10 Feb 2021 09:21:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwZVr4Sz1LtyYWVtsRiANAajsGPPqQRTm8avEn8NmnnAQGYlU5LJQyo7XTLpC2+kcMJZWCQ X-Received: by 2002:a17:906:1719:: with SMTP id c25mr4058714eje.251.1612977666211; Wed, 10 Feb 2021 09:21:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612977666; cv=none; d=google.com; s=arc-20160816; b=wPYPpsywUpY2IB87h423gYjmgRkI0JNO73vTfzLlWue6Q283TPvKugt5NuyOs7M/M6 0u1ekVVdQNHdQ1Knx/7Pc1MSBmAzM9dOQEu+2xXHcvF9sWE1joYUm7mM+RnTefIs0/ig NCoxtYpn6bgwMWo9npfSz9iYt3ubEvjvutWDNoLX5KhBrEFNfVIUXFQHRFincCCu/EKt G7fenOWXL9DDjewn0LTJ4zx3RGARVJKh8Y/AQKAric+MWwsOEbjdeocJgneTRzE9fOys OTQmYvhh4f000SgOEQnuJRNLhlQIlsBo5X6iJSwyuwBGVrzGNm9CHTSXmt+mDVS4x7jS /sSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=pnXK/IR7kwRHioWi4n+z2d1LBLzC5VDv46lVgWiUcLw=; b=o/bBya3avK245WF8p+aLByclv3SkKanTNfAO1OGkF6ARKMKwNbCgrnsbiYHms9APEg /GmM0NjsT75Z2mAHADgsFgBrtvNA2Y1H4Am9Ya8xc6qWKaWj7Wijx0na3tcMeNlVzvPv uA2zLeX4ZhOBcP8LtpXM3jw03lN/C1sXBlNtIcmlcbw7pdj1wWiGqz7hPxqf1XYLpS2G K9F67BaOeMU/7Ap59ocXixKRmBECFIAbX91j/o4+IjgpjxGfYYdi3Ik6ODETVWlshOWm c860dEaXZuLyUhBObYksFnzjqwJwXC7dMFX4x97fwKPTMRhWTixxJ0uRLomBZosMGPD1 CWug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mkk8Wppy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m1si1658388eje.652.2021.02.10.09.20.38; Wed, 10 Feb 2021 09:21:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mkk8Wppy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232207AbhBJRR0 (ORCPT + 99 others); Wed, 10 Feb 2021 12:17:26 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:54252 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232249AbhBJRQQ (ORCPT ); Wed, 10 Feb 2021 12:16:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612977291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnXK/IR7kwRHioWi4n+z2d1LBLzC5VDv46lVgWiUcLw=; b=Mkk8Wppyt/l3RtjZFlfPIcoh8E+/hu6EIJMJnSxKfK6QhKwCrSuL7beedPykVhnxR17UvJ lW4ghwTesdXdi2aC42bv8MHjGfZ75JHNz+kSwFlzV5XebyAoZ6fSMjad72I5+YutEoe//K gcssSHyzrcLrusOnMECxVfULNU+nkdY= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-414-IgicaziiOjiPdps8Nj9-fQ-1; Wed, 10 Feb 2021 12:14:49 -0500 X-MC-Unique: IgicaziiOjiPdps8Nj9-fQ-1 Received: by mail-wm1-f69.google.com with SMTP id u138so1213577wmu.8 for ; Wed, 10 Feb 2021 09:14:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pnXK/IR7kwRHioWi4n+z2d1LBLzC5VDv46lVgWiUcLw=; b=B8Shzoz4jFIvjU34mI+IlB48jIs3hodSS1apeqSK6apjWNom/OKxle0eZ/EoaTy7MS O49d8uhNlPfOi9tP9oLI7q9cyndPcuJtLl8qU0bnOt9BukqDjKvvIKURjSwQWg6ozRYm wsskRX9tAp0HOac7BaEVQzG8w/1mB2RyYJuSlzDennht+VJ/hXx9SUN5In6g4r946WtQ NWI2aAXLXelItVqOqg+HrGMta1boQRo+bCasACPc7DANeS8e5mfQ1bIDyIpPTGMloohr POfm6p8xZEI9v2BUENlqIbVGLviLbhwCplr6zBm/5YPC5rF7SEZdJ4QZD2l0SwrQnhiR 7iSg== X-Gm-Message-State: AOAM531xolvFHcJpFj/ghu9vu2tQFqYN0bE/YQ25rAOINWef4fBER/mh dNxvuUisKbeYH7WTOdUyxT4Oujl5x6k+pTENVi5NtDV8rw12AO22ABgph5a+yVlTpkkZIMgJ4oV lnx6BMLBIOEEkoWOb3tV9joq5 X-Received: by 2002:a05:6000:18a3:: with SMTP id b3mr4764947wri.373.1612977288615; Wed, 10 Feb 2021 09:14:48 -0800 (PST) X-Received: by 2002:a05:6000:18a3:: with SMTP id b3mr4764930wri.373.1612977288448; Wed, 10 Feb 2021 09:14:48 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id l83sm3440826wmf.4.2021.02.10.09.14.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Feb 2021 09:14:47 -0800 (PST) Subject: Re: [PATCH v3] KVM: x86/MMU: Do not check unsync status for root SP. To: Yu Zhang , seanjc@google.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org References: <20210209170111.4770-1-yu.c.zhang@linux.intel.com> From: Paolo Bonzini Message-ID: Date: Wed, 10 Feb 2021 18:14:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210209170111.4770-1-yu.c.zhang@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/21 18:01, Yu Zhang wrote: > In shadow page table, only leaf SPs may be marked as unsync; > instead, for non-leaf SPs, we store the number of unsynced > children in unsync_children. Therefore, in kvm_mmu_sync_root(), > sp->unsync shall always be zero for the root SP and there is > no need to check it. Remove the check, and add a warning > inside mmu_sync_children() to assert that the flags are used > properly. > > While at it, move the warning from mmu_need_write_protect() > to kvm_unsync_page(). > > Co-developed-by: Sean Christopherson > Signed-off-by: Sean Christopherson > Signed-off-by: Paolo Bonzini > Signed-off-by: Yu Zhang > --- > arch/x86/kvm/mmu/mmu.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 86af58294272..5f482af125b4 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -1995,6 +1995,12 @@ static void mmu_sync_children(struct kvm_vcpu *vcpu, > LIST_HEAD(invalid_list); > bool flush = false; > > + /* > + * Only 4k SPTEs can directly be made unsync, the parent pages > + * should never be unsyc'd. > + */ > + WARN_ON_ONCE(parent->unsync); > + > while (mmu_unsync_walk(parent, &pages)) { > bool protected = false; > > @@ -2502,6 +2508,8 @@ EXPORT_SYMBOL_GPL(kvm_mmu_unprotect_page); > > static void kvm_unsync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp) > { > + WARN_ON(sp->role.level != PG_LEVEL_4K); > + > trace_kvm_mmu_unsync_page(sp); > ++vcpu->kvm->stat.mmu_unsync; > sp->unsync = 1; > @@ -2524,7 +2532,6 @@ bool mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn, > if (sp->unsync) > continue; > > - WARN_ON(sp->role.level != PG_LEVEL_4K); > kvm_unsync_page(vcpu, sp); > } > > @@ -3406,8 +3413,7 @@ void kvm_mmu_sync_roots(struct kvm_vcpu *vcpu) > * mmu_need_write_protect() describe what could go wrong if this > * requirement isn't satisfied. > */ > - if (!smp_load_acquire(&sp->unsync) && > - !smp_load_acquire(&sp->unsync_children)) > + if (!smp_load_acquire(&sp->unsync_children)) > return; > > write_lock(&vcpu->kvm->mmu_lock); > Queued, thanks. Paolo