Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753417AbcD0OkX (ORCPT ); Wed, 27 Apr 2016 10:40:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36829 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752801AbcD0OkU (ORCPT ); Wed, 27 Apr 2016 10:40:20 -0400 Date: Wed, 27 Apr 2016 16:40:14 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Greg Kurz Cc: Paolo Bonzini , james.hogan@imgtec.com, mingo@redhat.com, linux-mips@linux-mips.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Hildenbrand , qemu-ppc@nongnu.org, Cornelia Huck , Paul Mackerras , David Gibson Subject: Re: [PATCH v4 1/2] KVM: remove NULL return path for vcpu ids >= KVM_MAX_VCPUS Message-ID: <20160427144010.GA27247@potion> References: <146124809455.32509.15232948272580716135.stgit@bahia.huguette.org> <146124810201.32509.2946887043729554992.stgit@bahia.huguette.org> <20160427054052.Horde.SSxGXKxS_wcijUfLJchjWw2@ltc.linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160427054052.Horde.SSxGXKxS_wcijUfLJchjWw2@ltc.linux.ibm.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 27 Apr 2016 14:40:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 891 Lines: 25 2016-04-27 05:40-0400, Gerg Kurz: > Quoting Greg Kurz : > >> Commit c896939f7cff ("KVM: use heuristic for fast VCPU lookup by id") added >> a return path that prevents vcpu ids to exceed KVM_MAX_VCPUS. This is a >> problem for powerpc where vcpu ids can grow up to 8*KVM_MAX_VCPUS. >> >> This patch simply reverses the logic so that we only try fast path if the >> vcpu id can be tried as an index in kvm->vcpus[]. The slow path is not >> affected by the change. >> >> Signed-off-by: Greg Kurz >> --- > > Radim, > > I think this sanity check is only needed because kvm_get_vcpu() use the > id as an index in kvm->vcpus[]. Checking against the new KVM_MAX_VCPU_ID > would be clearly wrong here. I agree, checking KVM_MAX_VCPU_ID would be pointless. > And this patch got two R-b tags already. Do you agree we keep it ? Yes, thanks.