linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH 1/2] KVM: x86/mmu: Protect marking SPs unsync when using TDP MMU with spinlock
Date: Wed, 11 Aug 2021 13:47:39 +0200	[thread overview]
Message-ID: <74bb6910-4a0c-4d2f-e6b5-714a3181638e@redhat.com> (raw)
In-Reply-To: <20210810224554.2978735-2-seanjc@google.com>

On 11/08/21 00:45, Sean Christopherson wrote:
> Use an entirely new spinlock even though piggybacking tdp_mmu_pages_lock
> would functionally be ok.  Usurping the lock could degrade performance when
> building upper level page tables on different vCPUs, especially since the
> unsync flow could hold the lock for a comparatively long time depending on
> the number of indirect shadow pages and the depth of the paging tree.

If we are to introduce a new spinlock, do we need to make it conditional 
and pass it around like this?  It would be simpler to just take it 
everywhere (just like, in patch 2, passing "shared == true" to 
tdp_mmu_link_page is always safe anyway).

Paolo


  reply	other threads:[~2021-08-11 11:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 22:45 [PATCH 0/2] KVM: x86/mmu: Fix unsync races within TDP MMU Sean Christopherson
2021-08-10 22:45 ` [PATCH 1/2] KVM: x86/mmu: Protect marking SPs unsync when using TDP MMU with spinlock Sean Christopherson
2021-08-11 11:47   ` Paolo Bonzini [this message]
2021-08-11 15:52     ` Sean Christopherson
2021-08-12 15:37       ` Paolo Bonzini
2021-08-12 16:06         ` Sean Christopherson
2021-08-10 22:45 ` [PATCH 2/2] KVM: x86/mmu: Drop 'shared' param from tdp_mmu_link_page() Sean Christopherson
2021-08-11 16:33   ` Ben Gardon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74bb6910-4a0c-4d2f-e6b5-714a3181638e@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bgardon@google.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).