Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932182AbdDGKzf (ORCPT ); Fri, 7 Apr 2017 06:55:35 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:43540 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753281AbdDGKzZ (ORCPT ); Fri, 7 Apr 2017 06:55:25 -0400 Subject: Re: [PATCH 2/6] KVM: use kvm_{test,clear}_request instead of {test,clear}_bit To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <20170406202056.18379-1-rkrcmar@redhat.com> <20170406202056.18379-3-rkrcmar@redhat.com> Cc: Christoffer Dall , Andrew Jones , Marc Zyngier , Paolo Bonzini , Cornelia Huck , James Hogan , Paul Mackerras From: Christian Borntraeger Date: Fri, 7 Apr 2017 12:55:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170406202056.18379-3-rkrcmar@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 17040710-0056-0000-0000-0000033217EB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006892; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00844230; UDB=6.00416124; IPR=6.00622528; BA=6.00005275; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014947; XFM=3.00000013; UTC=2017-04-07 10:55:20 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17040710-0057-0000-0000-000007681C12 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-07_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070092 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1182 Lines: 40 On 04/06/2017 10:20 PM, Radim Krčmář wrote: > Users were expected to use kvm_check_request() for testing and clearing, > but request have expanded their use since then and some users want to > only test or do a faster clear. > > Make sure that requests are not directly accessed with bit operations, because > we'll be clearing them later. > > Signed-off-by: Radim Krčmář Patch itself looks sane Reviewed-by: Christian Borntraeger one question: > static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu) > { > - if (test_bit(req, &vcpu->requests)) { > - clear_bit(req, &vcpu->requests); > + if (kvm_test_request(req, vcpu)) { > + kvm_clear_request(req, vcpu); This looks fine. I am just asking myself why we do not use test_and_clear_bit? Do we expect gcc to merge all test bits as a fast path? This does not seem to work as far as I can tell and almost everybody does a fast path like in arch/s390/kvm/kvm-s390.c: if (!vcpu->requests) return 0; arch/x86/kvm/x86.c: if (vcpu->requests) { > > /* > * Ensure the rest of the request is visible to kvm_check_request's >