From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.10832.1679399620169471992 for ; Tue, 21 Mar 2023 04:53:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L6uuZ0Zd; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679399619; 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: in-reply-to:in-reply-to:references:references; bh=hSqinDSsWhrJKMqWeN5AWVgEYB2KPd4/XrD6203Uiyk=; b=L6uuZ0ZdXskul+e2+QIlF08wgnpu2GWKito48Evy+AWVtk81NY/74b2CK0IeT4AdWvia8f oqpjBiFNTUMucOohw9WEMOU3VFwtHiO5vDWPXpC3BRdc5dtzHeb1XUKFKA/BpOHJ3hjU5+ aR82UBoV1QXv+SdYObxy00AwQTVqsPs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-96-R-G8tZEcM_-iZuiCCFxcOw-1; Tue, 21 Mar 2023 07:53:36 -0400 X-MC-Unique: R-G8tZEcM_-iZuiCCFxcOw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9A12D855300; Tue, 21 Mar 2023 11:53:35 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.144]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6F54F40B934; Tue, 21 Mar 2023 11:53:35 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1E2FE1800081; Tue, 21 Mar 2023 12:53:34 +0100 (CET) Date: Tue, 21 Mar 2023 12:53:34 +0100 From: "Gerd Hoffmann" To: "Ni, Ray" Cc: "devel@edk2.groups.io" , Pawel Polawski , "Kumar, Rahul R" , Oliver Steffen , "Dong, Eric" Subject: Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg/MpInitLib: fix apic mode for cpu hotplug Message-ID: <20230321115334.zq2spdxy3gfpvy2q@sirius.home.kraxel.org> References: <20230307122037.3100651-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 21, 2023 at 07:28:44AM +0000, Ni, Ray wrote: > > + } else if ((PcdGet32 (PcdCpuBootLogicalProcessorNumber) > 0) && > > + (PcdGet32 (PcdCpuMaxLogicalProcessorNumber) > 255)) > > + { > > + X2Apic = TRUE; > > Gerd, > I agree with your needs that want X2 APIC even the actual processor number in BIOS phase <= 255. > > Question: Is it possible that BIOS stays at XAPIC, and later OS switches to X2 APIC when the maximum CPU count > 255? Linux doesn't do that. In case x2apic mode is not active at boot the number of CPUs will be limited to 255. > I am thinking about adding a new PCD to tell MP code switch to x2 apic > in the first time AP wakes up. Possible timeline for the code change > is about within 1 month. Do you think it can meet your needs? So the idea being that OVMF simply sets that PCD if needed (probably at the same place where PcdCpuMaxLogicalProcessorNumber is set)? That would work too. take care, Gerd