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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9F572ECAAA3 for ; Fri, 26 Aug 2022 15:30:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gg+IGYtPwRVyi9kNa9VisFnCAvfLPyWVrHupNNS6vx4=; b=JS+4fc53GKwnF7 YYqG5DUvaypC14VhtPin3qGLdMPmEyzPD9pBTXJHgX3PsdYehBe+RUD1YQpzipbM6XB2d79AzWXKj 0huNKE5TNjlLh6lLuy+mE0f6WCOMZQ7adrCw+CVZRgGmjLdn2h9ccNh7F/zRHlnVXlgJ9W56xZ+2l sQ4uttJc8DpRfzRoA8G5W9QVaQ8zAqtw6rfGhB1hjer5JjTakYr95kQRGcyY2HKOv8yKjFPHJR/uq pkXcfyAmRVgNhFveY9EQO9l8sT7J68PZr61SX4Edo6e5kE2Tg8WC48RRc5gVpX9JZflvBWfUH50F/ 2lHHkkigEF/HyEH65BRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRbGY-006zzh-7O; Fri, 26 Aug 2022 15:29:02 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oRbGU-006zw9-N8 for linux-arm-kernel@lists.infradead.org; Fri, 26 Aug 2022 15:29:00 +0000 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 sin.source.kernel.org (Postfix) with ESMTPS id 00167CE3032; Fri, 26 Aug 2022 15:28:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43CC0C433C1; Fri, 26 Aug 2022 15:28:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661527734; bh=9sSbYtj6HrSqCiQbWoqDnd2lqwf/GjZezh1mnrUlOIo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NtVyh+M70kH2bajohPpEeO+dqnJzQ9HQupJyzrcFn50OC3kiLZ649xujbopMiHgP0 dd04NWb9xkhl5vwcX9pEz+tZNTXdoE4fzTnJkVPl/gtzDz9RxprHVg4uL1ZZna9iDZ LIiMoklsMJwqsAMubakiBrGULCW5pnIedneig2F0BrOFjE2hVLbQnsvN8HntK/FUWK KtO3QI/essFpL9JMjKf1JM2bx74fSFbirYfhslnPtbzNy/u6G9wRgngckG0UIVBiaJ HpGRdcaMfiCUHYpCwTeMtCpCY9o6UudtTjHDt1s8m/PCMS7/w+3TPCMOKSfUGVYF0S GLLDiSMn5nNxA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1oRbGO-005z5p-0G; Fri, 26 Aug 2022 16:28:52 +0100 Date: Fri, 26 Aug 2022 16:28:51 +0100 Message-ID: <874jxzvxak.wl-maz@kernel.org> From: Marc Zyngier To: Paolo Bonzini Cc: Oliver Upton , Gavin Shan , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, peterx@redhat.com, corbet@lwn.net, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, seanjc@google.com, drjones@redhat.com, dmatlack@google.com, bgardon@google.com, ricarkol@google.com, zhenyzha@redhat.com, shan.gavin@gmail.com Subject: Re: [PATCH v1 1/5] KVM: arm64: Enable ring-based dirty memory tracking In-Reply-To: <99364855-b4e9-8a69-e1ca-ed09d103e4c8@redhat.com> References: <20220819005601.198436-1-gshan@redhat.com> <20220819005601.198436-2-gshan@redhat.com> <87lerkwtm5.wl-maz@kernel.org> <41fb5a1f-29a9-e6bb-9fab-4c83a2a8fce5@redhat.com> <87fshovtu0.wl-maz@kernel.org> <87a67uwve8.wl-maz@kernel.org> <99364855-b4e9-8a69-e1ca-ed09d103e4c8@redhat.com> 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: pbonzini@redhat.com, oliver.upton@linux.dev, gshan@redhat.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, peterx@redhat.com, corbet@lwn.net, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org, seanjc@google.com, drjones@redhat.com, dmatlack@google.com, bgardon@google.com, ricarkol@google.com, zhenyzha@redhat.com, shan.gavin@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220826_082859_148550_8DAD18B5 X-CRM114-Status: GOOD ( 17.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 26 Aug 2022 11:58:08 +0100, Paolo Bonzini wrote: > > On 8/23/22 22:35, Marc Zyngier wrote: > >> Heh, yeah I need to get that out the door. I'll also note that Gavin's > >> changes are still relevant without that series, as we do write unprotect > >> in parallel at PTE granularity after commit f783ef1c0e82 ("KVM: arm64: > >> Add fast path to handle permission relaxation during dirty logging"). > > > > Ah, true. Now if only someone could explain how the whole > > producer-consumer thing works without a trace of a barrier, that'd be > > great... > > Do you mean this? > > void kvm_dirty_ring_push(struct kvm_dirty_ring *ring, u32 slot, u64 offset) Of course not. I mean this: static int kvm_vm_ioctl_reset_dirty_pages(struct kvm *kvm) { unsigned long i; struct kvm_vcpu *vcpu; int cleared = 0; if (!kvm->dirty_ring_size) return -EINVAL; mutex_lock(&kvm->slots_lock); kvm_for_each_vcpu(i, vcpu, kvm) cleared += kvm_dirty_ring_reset(vcpu->kvm, &vcpu->dirty_ring); [...] } and this int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_dirty_ring *ring) { u32 cur_slot, next_slot; u64 cur_offset, next_offset; unsigned long mask; int count = 0; struct kvm_dirty_gfn *entry; bool first_round = true; /* This is only needed to make compilers happy */ cur_slot = cur_offset = mask = 0; while (true) { entry = &ring->dirty_gfns[ring->reset_index & (ring->size - 1)]; if (!kvm_dirty_gfn_harvested(entry)) break; [...] } which provides no ordering whatsoever when a ring is updated from one CPU and reset from another. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel