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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4CF2C32771 for ; Sat, 24 Sep 2022 08:51:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1A8AB40B91; Sat, 24 Sep 2022 04:51:47 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-+cRatqvP3T; Sat, 24 Sep 2022 04:51:45 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C60A140C1B; Sat, 24 Sep 2022 04:51:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E215940BA9 for ; Sat, 24 Sep 2022 04:51:44 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVPZoBBpmVE0 for ; Sat, 24 Sep 2022 04:51:43 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id B944140B91 for ; Sat, 24 Sep 2022 04:51:43 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A897F611A7; Sat, 24 Sep 2022 08:51:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11E81C433D7; Sat, 24 Sep 2022 08:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664009502; bh=sQu4rY26atOOmUOcr/UZfhpKLw2nqwuD8y4ts7N3Xq0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PiyTCrM2xF8ErVB2yED85XFj/4tDY3E88aPmH5y3W2wUTaKNtbXN5cYHylLyxBqe3 Yo7xEMMwMlk5ozGWNTQ8cFGcIr7ZC5syNJUw0nz/kTVZZft0NGFjaTrJIxdpMn5m0U MAGMQhZhr1R/cnId1GnW6dy+LF3IJ7AFS9B7NWBKGfYV8e9Bfh6qy204x+NLBp22vA bV4ii57bzUiiCa8vbWbenac8eoxdcI1TFB58antGyZrYILHubsrylc6PrEror27Nk9 yq5uwf5M64kmt3+Fu/RBF0gOBJOAbK3eojTowF4/UL3Lhrb2uMKaeAiOuIQXwN/OB9 AcFI7BFKpxsrQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oc0st-00CJhn-Td; Sat, 24 Sep 2022 09:51:40 +0100 Date: Sat, 24 Sep 2022 09:51:39 +0100 Message-ID: <87edw1i290.wl-maz@kernel.org> From: Marc Zyngier To: Peter Xu Subject: Re: [PATCH 2/6] KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option In-Reply-To: References: <20220922170133.2617189-1-maz@kernel.org> <20220922170133.2617189-3-maz@kernel.org> <87czbmjhbh.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: peterx@redhat.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, catalin.marinas@arm.com, bgardon@google.com, shuah@kernel.org, andrew.jones@linux.dev, will@kernel.org, dmatlack@google.com, pbonzini@redhat.com, zhenyzha@redhat.com, shan.gavin@gmail.com, gshan@redhat.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, oliver.upton@linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, catalin.marinas@arm.com, andrew.jones@linux.dev, will@kernel.org, shan.gavin@gmail.com, bgardon@google.com, dmatlack@google.com, pbonzini@redhat.com, zhenyzha@redhat.com, shuah@kernel.org, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Fri, 23 Sep 2022 19:26:18 +0100, Peter Xu wrote: > > On Fri, Sep 23, 2022 at 03:28:34PM +0100, Marc Zyngier wrote: > > On Thu, 22 Sep 2022 22:48:19 +0100, > > Peter Xu wrote: > > > > > > On Thu, Sep 22, 2022 at 06:01:29PM +0100, Marc Zyngier wrote: > > > > In order to differenciate between architectures that require no extra > > > > synchronisation when accessing the dirty ring and those who do, > > > > add a new capability (KVM_CAP_DIRTY_LOG_RING_ORDERED) that identify > > > > the latter sort. TSO architectures can obviously advertise both, while > > > > relaxed architectures most only advertise the ORDERED version. > > > > > > > > Suggested-by: Paolo Bonzini > > > > Signed-off-by: Marc Zyngier > > > > --- > > > > include/linux/kvm_dirty_ring.h | 6 +++--- > > > > include/uapi/linux/kvm.h | 1 + > > > > virt/kvm/Kconfig | 14 ++++++++++++++ > > > > virt/kvm/Makefile.kvm | 2 +- > > > > virt/kvm/kvm_main.c | 11 +++++++++-- > > > > 5 files changed, 28 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/include/linux/kvm_dirty_ring.h b/include/linux/kvm_dirty_ring.h > > > > index 906f899813dc..7a0c90ae9a3f 100644 > > > > --- a/include/linux/kvm_dirty_ring.h > > > > +++ b/include/linux/kvm_dirty_ring.h > > > > @@ -27,7 +27,7 @@ struct kvm_dirty_ring { > > > > int index; > > > > }; > > > > > > > > -#ifndef CONFIG_HAVE_KVM_DIRTY_RING > > > > +#ifndef CONFIG_HAVE_KVM_DIRTY_LOG > > > > > > s/LOG/LOG_RING/ according to the commit message? Or the name seems too > > > generic. > > > > The commit message talks about the capability, while the above is the > > config option. If you find the names inappropriate, feel free to > > suggest alternatives (for all I care, they could be called FOO, BAR > > and BAZ). > > The existing name from David looks better than the new one.. to me. I'm happy to bikeshed, but please spell it out for me. If we follow the current scheme, we need 3 configuration symbols (of which we already have one), and 2 capabilities (of which we already have one). Do you have any concrete proposal for those? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm