Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753032AbcJOHru convert rfc822-to-8bit (ORCPT ); Sat, 15 Oct 2016 03:47:50 -0400 Received: from mx5-phx2.redhat.com ([209.132.183.37]:48736 "EHLO mx5-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbcJOHrt (ORCPT ); Sat, 15 Oct 2016 03:47:49 -0400 Date: Sat, 15 Oct 2016 03:47:45 -0400 (EDT) From: Paolo Bonzini To: Nadav Amit Cc: LKML , KVM , Radim =?utf-8?B?S3LEjW3DocWZ?= , Yang Zhang , feng wu , mst@redhat.com Message-ID: <119879133.3749907.1476517665517.JavaMail.zimbra@redhat.com> In-Reply-To: <9B7F4808-2294-426D-B463-CEB188CED2E0@gmail.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> Subject: Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.4.164.1, 10.5.100.50] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF49 (Linux)/8.0.6_GA_5922) Thread-Topic: x86: avoid atomic operations on APICv vmentry Thread-Index: mILmtPVerDqfiCFInJ0/a0oe5ADvpg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 888 Lines: 24 > > 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