Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp375265pxm; Fri, 25 Feb 2022 09:38:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJwxjgCFSkN5WqzJu5IQ8FZE0NfCHYdK0zPOIFVQuJx8bI1U9cINgmquOr39SBn0DW0EwoR9 X-Received: by 2002:a17:902:f643:b0:14d:7b8f:14b3 with SMTP id m3-20020a170902f64300b0014d7b8f14b3mr8407211plg.19.1645810683703; Fri, 25 Feb 2022 09:38:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645810683; cv=none; d=google.com; s=arc-20160816; b=DzV5x1IOGdoJcgL7H+DRLq9yjC8d7ntZx2BcijbEA6nB/OHpdZbJXIZFXn8iYU6ouk S05k7JrGxJjlmTueZ7mfDd1DqK9qHQShrYVqcO7HVjt/oNVr1s9VS7UVfGkcSn1MtEuR lLCDVcGzc1LiIUlYkZh1eCZkk2GplYN+6ZaUGQ/FwaAJl2CPulBj2118nSZciXPhZ8kF J2N4f6eGu0TewORvDtK7nLZKBjPVZSp6ymHuz13u8TXW+WdRbDW+UCI+rRoYOXv1cUd2 jMWMYz5ppA5+jLCQqAzyNCSEnX2P4/xLPqWJdILOTUSPpPyFItAAg9NKwM3kvhcJiLpP U+5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=xxNAibxsiiU2bHsBXx2buGz12V3hEqmNOWKO5gCjbww=; b=nDfcmMO6eQ/nhcHHqst+B42rIigvITkCnKJOW6m9hzfEY3AuluHVQ8c9sEe/ZeAu0p SF4F4kCt6gA8nNeDZJizVGAVOOUJ4F7am1kMz7UapC7NwTLgVrSTF+/9yjQQQkuHDLlK iuYYsvNvf6j5q8O4GRxmIG9xepYEg4zdE8et6D22BcKE1ORxvD5dl1JGidO4iX+4QHt/ s65kQhY2FLy+udDNbppHdy9va0bVhfoZSoOugcNLY6naQquSvPVMn/P3m5mdLov570mT ALRVoWWzmIi0wlNt8Mtz+eelSLCj7SJmZVyyCe7drE/Ca1qlpKPOzpNChlmQBK8BmkLJ Ux9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JsPye5wz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n8-20020a170902e54800b0014993d79146si2423355plf.556.2022.02.25.09.37.47; Fri, 25 Feb 2022 09:38:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JsPye5wz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242680AbiBYQOD (ORCPT + 99 others); Fri, 25 Feb 2022 11:14:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235775AbiBYQOB (ORCPT ); Fri, 25 Feb 2022 11:14:01 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6FE96134DCC for ; Fri, 25 Feb 2022 08:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645805608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xxNAibxsiiU2bHsBXx2buGz12V3hEqmNOWKO5gCjbww=; b=JsPye5wzxW+aq/a6E+lErGOhRLaXAOxasLor6/cN3fNJN2aj+LPMJLAzaYawT1cCtZ2xdP 20o8G40e7cI2oACzB8oJ+AjsRNmEZIzFxOBiAYtEz4JFpPUBHbNlV4jYlzjJtOHiYncXIh XE+SRar7D9KiMNk8n52T/yheAd/70VY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-178-439FHvLDMqa5-AmaKbS38A-1; Fri, 25 Feb 2022 11:13:25 -0500 X-MC-Unique: 439FHvLDMqa5-AmaKbS38A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8B4EB1006AA5; Fri, 25 Feb 2022 16:13:21 +0000 (UTC) Received: from starship (unknown [10.40.195.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3565C8379F; Fri, 25 Feb 2022 16:12:41 +0000 (UTC) Message-ID: <57e91d8f75d6e39432a2fef5d899e3238154863f.camel@redhat.com> Subject: Re: [PATCH v6 6/9] KVM: x86: lapic: don't allow to change APIC ID unconditionally From: Maxim Levitsky To: David Woodhouse , Zeng Guang , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, Dave Hansen , Tony Luck , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , Kai Huang Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Robert Hu , Gao Chao Date: Fri, 25 Feb 2022 18:12:41 +0200 In-Reply-To: <38b6a762bea2cdbe5e761daf5dbc351b18f28de3.camel@infradead.org> References: <20220225082223.18288-1-guang.zeng@intel.com> <20220225082223.18288-7-guang.zeng@intel.com> <79f5ce60c65280f4fb7cba0ceedaca0ff5595c48.camel@redhat.com> <38b6a762bea2cdbe5e761daf5dbc351b18f28de3.camel@infradead.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-02-25 at 15:42 +0000, David Woodhouse wrote: > On Fri, 2022-02-25 at 17:11 +0200, Maxim Levitsky wrote: > > On Fri, 2022-02-25 at 14:56 +0000, David Woodhouse wrote: > > > On Fri, 2022-02-25 at 16:46 +0200, Maxim Levitsky wrote: > > > > Assuming that this is approved and accepted upstream, > > > > that is even better that my proposal of doing this > > > > when APICv is enabled. > > > > > > > > Since now apic id is always read only, now we should not > > > > forget to clean up some parts of kvm like kvm_recalculate_apic_map, > > > > which are not needed anymore > > > > > > Can we also now optimise kvm_get_vcpu_by_id() so it doesn't have to do > > > a linear search over all the vCPUs when there isn't a 1:1 > > > correspondence with the vCPU index? > > > > I don't think so since vcpu id can still be set by userspace to anything, > > and this is even used to encode topology in it. > > Yes, but it can only be set at vCPU creation time and it has to be > unique. > > > However a hash table can still be used there to speed it up regardless of > > read-only apic id IMHO. > > > > Or, even better than a hash table, I see that KVM already > > limits vcpu_id to KVM_MAX_VCPUS * 4 with a comment that only two extra > > bits of topology are used: > > We already have the kvm_apic_map which provides a fast lookup. The key > point here is that the APIC ID can't *change* from vcpu->vcpu_id any > more, so we can actually use the kvm_apic_map for kvm_get_vcpu_by_id() > now, can't we? > Right! I wrote my response partially when I still assumed that vcpu_id can be any 32 bit number (thus hash table), and later checked that it is capped by KVM_MAX_VCPUS * 4 which isn't a big number, plus as I now see in the kvm_recalculate_apic_map the map is dynamically allocated up to the max apic id. (technically speaking an array is a hash table). Now the map would only be needed to be rebuit few times when new vCPUs are added, and can be used to locate vcpu by its apic id. I so hope that this patch is accepted so all of this could be done. Best regards, Maxim Levitsky