From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry Date: Wed, 19 Oct 2016 04:45:48 -0700 Message-ID: <20161019114548.GL3716@linux.vnet.ibm.com> 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> <20161016052132-mutt-send-email-mst@kernel.org> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Paolo Bonzini , Nadav Amit , LKML , KVM , Radim =?utf-8?B?S3LEjW3DocWZ?= , Yang Zhang , feng wu , Jonathan Corbet To: "Michael S. Tsirkin" Return-path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60105 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753095AbcJSR5O (ORCPT ); Wed, 19 Oct 2016 13:57:14 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9JHs9G6052780 for ; Wed, 19 Oct 2016 13:57:13 -0400 Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by mx0a-001b2d01.pphosted.com with ESMTP id 266c6w5bn0-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Oct 2016 13:57:13 -0400 Received: from localhost by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 19 Oct 2016 11:57:12 -0600 Content-Disposition: inline In-Reply-To: <20161016052132-mutt-send-email-mst@kernel.org> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Oct 16, 2016 at 05:29:24AM +0300, Michael S. Tsirkin wrote: > 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). One concern would be the guy reading the code, to whom it might not be obvious that the underlying access was volatile, especially if the reference was a few levels down. Thanx, Paul