Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755269AbcJPCbR (ORCPT ); Sat, 15 Oct 2016 22:31:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49890 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754403AbcJPCbM (ORCPT ); Sat, 15 Oct 2016 22:31:12 -0400 Date: Sun, 16 Oct 2016 05:29:24 +0300 From: "Michael S. Tsirkin" To: Paolo Bonzini Cc: Nadav Amit , LKML , KVM , Radim =?utf-8?B?S3LEjW3DocWZ?= , Yang Zhang , feng wu , "Paul E. McKenney" , Jonathan Corbet Subject: Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry Message-ID: <20161016052132-mutt-send-email-mst@kernel.org> References: <1476469291-5039-1-git-send-email-pbonzini@redhat.com> <1476469291-5039-2-git-send-email-pbonzini@redhat.com> <4B0C832B-BB75-40BD-85A9-9DC84DEB44E2@gmail.com> <770436977.3704467.1476471398385.JavaMail.zimbra@redhat.com> <9B7F4808-2294-426D-B463-CEB188CED2E0@gmail.com> <119879133.3749907.1476517665517.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <119879133.3749907.1476517665517.JavaMail.zimbra@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sun, 16 Oct 2016 02:29:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1524 Lines: 41 On Sat, Oct 15, 2016 at 03:47:45AM -0400, Paolo Bonzini wrote: > > > > On Oct 14, 2016, at 11:56 AM, Paolo Bonzini wrote: > > >>> > > >>> for (i = 0; i <= 7; i++) { > > >>> - pir_val = xchg(&pir[i], 0); > > >>> - if (pir_val) > > >>> + pir_val = READ_ONCE(pir[i]); > > >> > > >> Out of curiosity, do you really need this READ_ONCE? > > > > > > The answer can only be "depends on the compiler's whims". :) > > > If you think of READ_ONCE as a C11 relaxed atomic load, then yes. > > > > Hm.. So the idea is to make the code "race-free” in the sense > > that every concurrent memory access is done using READ_ONCE/WRITE_ONCE? > > > > If that is the case, I think there are many other cases that need to be > > changed, for example apic->irr_pending and vcpu->arch.pv.pv_unhalted. > > There is no documentation for this in the kernel tree unfortunately. > But yes, I think we should do that. Using READ_ONCE/WRITE_ONCE around > memory barriers is a start. > > Paolo I'm beginning to think that if a value is always (maybe except for init where we don't much care about the code size anyway) accessed through *_ONCE macros, we should just mark it volatile and be done with it. The code will look cleaner, and there will be less space for errors like forgetting *_ONCE macros. Would such code (where all accesses are done through READ_ONCE/WRITE_ONCE otherwise) be an exception to volatile-considered-harmful.txt rules? Cc Paul and Jonathan (for volatile-considered-harmful.txt). -- MST