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 03158C32771 for ; Sat, 24 Sep 2022 08:48:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6DD4840BEF; Sat, 24 Sep 2022 04:48:10 -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 i8R406AkTIEk; Sat, 24 Sep 2022 04:48:09 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4100340C1B; Sat, 24 Sep 2022 04:48:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DC3D540B91 for ; Sat, 24 Sep 2022 04:48:07 -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 mpfJ1DmTj2Sb for ; Sat, 24 Sep 2022 04:48:06 -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 92AA240BEF for ; Sat, 24 Sep 2022 04:48:06 -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 A56B761133; Sat, 24 Sep 2022 08:48:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16992C433C1; Sat, 24 Sep 2022 08:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664009285; bh=YOpODT4va0VloCZOBnvQvpP8J5R28QS/wmKHIPcpRE4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Z/o2gU2p8Urtm0xeFGOkNZE62b7hAAJaRgGLqXhpavIfWjQIvVL+8bR6WL4otUCFW +pdMiJ/O2NaLus1f+lA35EU4Xh0AXjXpp/bniJ6nbu8x/o0ylwhqYit1OKMkPVVBiv IwYw3V28nwUjT2vEf8ibe7gCKw5HpCX3GHCUVyxDcdv44Gpkb6lZiA1t0ASF+jPo4V T06FQ4O7a+TjgkJMjnIEoIHP6LvuvnmJxJ4M4QmCtAb9PYfz0A14aKKoy4L1M93+f4 Q1xlOofZBtC5nZGoXQMn+T09A+GtYifkgFjMcg1LkqMRibnZ5544yDJDiMk251QM5z zomhXXj0WxSRg== 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 1oc0pO-00CJg2-Ui; Sat, 24 Sep 2022 09:48:03 +0100 Date: Sat, 24 Sep 2022 09:47:59 +0100 Message-ID: <87fsghi2f4.wl-maz@kernel.org> From: Marc Zyngier To: Peter Xu Subject: Re: [PATCH 3/6] KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ORDERED In-Reply-To: References: <20220922170133.2617189-1-maz@kernel.org> <20220922170133.2617189-4-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 23:46:40 +0100, Peter Xu wrote: > > On Thu, Sep 22, 2022 at 06:01:30PM +0100, Marc Zyngier wrote: > > Since x86 is TSO (give or take), allow it to advertise the new > > ORDERED version of the dirty ring capability. No other change is > > required for it. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/x86/kvm/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > > index e3cbd7706136..eb63bc31ed1d 100644 > > --- a/arch/x86/kvm/Kconfig > > +++ b/arch/x86/kvm/Kconfig > > @@ -29,6 +29,7 @@ config KVM > > select HAVE_KVM_PFNCACHE > > select HAVE_KVM_IRQFD > > select HAVE_KVM_DIRTY_RING > > + select HAVE_KVM_DIRTY_RING_ORDERED > > select IRQ_BYPASS_MANAGER > > select HAVE_KVM_IRQ_BYPASS > > select HAVE_KVM_IRQ_ROUTING > > Before patch 2-3, we only have HAVE_KVM_DIRTY_RING. > > After that, we'll have: > > HAVE_KVM_DIRTY_LOG > HAVE_KVM_DIRTY_RING > HAVE_KVM_DIRTY_RING_ORDERED > > I'm wondering whether we can just keep using the old HAVE_KVM_DIRTY_RING, > but just declare a new KVM_CAP_DIRTY_LOG_RING_ORDERED only after all memory > barrier patches merged (after patch 1). The problem is to decide, on a per architecture basis, how to expose the old property. I'm happy to key it on being x86 specific, but that feels pretty gross, and totally unnecessary for strongly ordered architectures (s390?). > IIUC it's a matter of whether any of the arch would like to support > !ORDERED version of dirty ring at all, but then IIUC we'll need to have the > memory barriers conditional too or not sure how it'll help. Memory barriers do not affect the semantics of the userspace, while the lack thereof do. On strongly ordered architectures, acquire/release is usually "free", because that's implied by their memory model. If it thus free for these to implement both versions of the API. So are we discussing the cost of couple of (mostly invisible) config options? 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