From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2CE5C433E0 for ; Thu, 21 Jan 2021 20:21:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6BD7223A54 for ; Thu, 21 Jan 2021 20:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727248AbhAUUVN (ORCPT ); Thu, 21 Jan 2021 15:21:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:28499 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726286AbhAUUTK (ORCPT ); Thu, 21 Jan 2021 15:19:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611260256; 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=VohorfWzk+8yRDGlB2g34QP+eQheRXpXwnsYx6YP7js=; b=JYOf1ZZe2DBVO8utcmSP+8kg+2cp+uI7vowB3PeCo7ijDCnzTzEQGVPjwX+9/vz7Eaixsy VHTSGJIhYaTZNX4GSDqVttTh1tQTJaHpFDt4GRG/GPcR9qzZdqXxj+WhGta32u1HLQJyz3 jARVGp6bhnpNmIvAVz221koBeIk18Sw= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-364-FrQEyUe0N2el_ZtFHNN-Ow-1; Thu, 21 Jan 2021 15:17:35 -0500 X-MC-Unique: FrQEyUe0N2el_ZtFHNN-Ow-1 Received: by mail-wr1-f70.google.com with SMTP id x12so1793391wrw.21 for ; Thu, 21 Jan 2021 12:17:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VohorfWzk+8yRDGlB2g34QP+eQheRXpXwnsYx6YP7js=; b=iAHo6R4Ik1xF4kGKej8AX8jUaNk2aQ1ropfMZEx8TCbUBj0pKHqJv+7N2d79d6dzGl jetTpZbBRe0O/WNHNJgDtg9mR5dJSkHEbuZIgljMP+xMMN1pXD6H3EgV2Az5kLsgAk8G EXcHaUxHHMJatR+FELcJiNLtJ9Rymh8v7YuPcHeOwwVkqOJ8vltz0iBOTr95tCf8PHmV X99HkTYnmu9EvBhQrBwT7k/DMMtOoE8qIRAik8kHIyPhyXK6Ceoom3rzmgVg8oHs70K1 I9ppjw1Zcfq3wYeNr0Rx6vbic8SHKkCpOo3aE3vu5mJKt/6x5pDLo4JXsnYqUL0bZqqx R11g== X-Gm-Message-State: AOAM5338ampNqIlxBLP6KFZcSMSgYemOR9thZTtV3AOf4rR2vHleUplm HAKwK4+T40Dzp1KxYdrVwgsr3NH2bI6AMRpDIo563tEEm9IhlmotFhL5HovS01SFhuvQ9aqprxr lpnXIKLX17AMyxnw4+8IP9sTS X-Received: by 2002:adf:dc8d:: with SMTP id r13mr1089279wrj.325.1611260254008; Thu, 21 Jan 2021 12:17:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7UUFXpIhrtay7ZHpDKjdSukAnA/VRU8c2t13/MOt/RngEZ928SqFHJITIawpWdsFo5CF46g== X-Received: by 2002:adf:dc8d:: with SMTP id r13mr1089258wrj.325.1611260253835; Thu, 21 Jan 2021 12:17:33 -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 c16sm9481816wrx.51.2021.01.21.12.17.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 12:17:32 -0800 (PST) To: Sean Christopherson , Ben Gardon , Marc Zyngier , Will Deacon , Paul Mackerras Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Peter Xu , Peter Shier , Peter Feiner , Junaid Shahid , Jim Mattson , Yulei Zhang , Wanpeng Li , Vitaly Kuznetsov References: <20210112181041.356734-1-bgardon@google.com> <20210112181041.356734-16-bgardon@google.com> From: Paolo Bonzini Subject: Re: [PATCH 15/24] kvm: mmu: Wrap mmu_lock cond_resched and needbreak Message-ID: <82c4d5da-2a28-558c-5e17-d837005b8d76@redhat.com> Date: Thu, 21 Jan 2021 21:17:31 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/01/21 01:19, Sean Christopherson wrote: > IMO, moving the lock to arch-specific code is bad for KVM. The > architectures' MMUs already diverge pretty horribly, and once things > diverge it's really hard to go the other direction. And this change, > along with all of the wrappers, thrash a lot of code and add a fair > amount of indirection without any real benefit to the other > architectures. What if we simply make the common mmu_lock a union? The > rwlock_t is probably a bit bigger, but that's a few bytes for an entire > VM. And maybe this would entice/inspire other architectures to move to a > similar MMU model. I agree. Most architectures don't do the lockless tricks that x86 do, and being able to lock for read would be better than nothing. For example, I took a look at ARM and stage2_update_leaf_attrs could be changed to operate in cmpxchg-like style while holding the rwlock for read. Paolo > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index f3b1013fb22c..bbc8efd4af62 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -451,7 +451,10 @@ struct kvm_memslots { > }; > > struct kvm { > - spinlock_t mmu_lock; > + union { > + rwlock_t mmu_rwlock; > + spinlock_t mmu_lock; > + }; > struct mutex slots_lock; > struct mm_struct *mm; /* userspace tied to this vm */ > struct kvm_memslots __rcu *memslots[KVM_ADDRESS_SPACE_NUM];