From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by mx.groups.io with SMTP id smtpd.web10.996.1601050205135295080 for ; Fri, 25 Sep 2020 09:10:05 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@hpe.com header.s=pps0720 header.b=AywVbEWf; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=05373d17cf=brian.johnson@hpe.com) Received: from pps.filterd (m0148663.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08PG9YMd006093; Fri, 25 Sep 2020 16:10:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pps0720; bh=Seva55oGE3sXxWuzy1iYU62ydeV/dtpxnkSFe6fwkOk=; b=AywVbEWfpWSYFQgr621+P+Y0iIe8bFTCIJjnhWaYRzaFRpIAv8jVpJNNAMWPKRVukeAa xJN1BJTzukJppdiDxbZzyyzLEMuGgvyZXw136qkg6N0nfr3lBF0OgE4o+/fAfhG6gbm3 DJdW8NyWnSKoH68yN5w9aM3YSO7pnFA4S107FerSlZzAYAruwEotUXLjUbalz2p4doCB xrfFAMxah5baVRZWX5xnqeAt0OjKSWjuzzYegaj+juDvxXm5sX6sYlBNWOrZo7r0sjrU 0v0HUkrSGeG7k+6TAsJ9GL21mWCRrd6wHcyEBd5d5vEobDJ4eR+hIXJiRnyVJYcx7FMf 6A== Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) by mx0a-002e3701.pphosted.com with ESMTP id 33rg4fy8e2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Sep 2020 16:10:02 +0000 Received: from g2t2360.austin.hpecorp.net (g2t2360.austin.hpecorp.net [16.196.225.135]) by g2t2354.austin.hpe.com (Postfix) with ESMTP id E4D1891; Fri, 25 Sep 2020 16:10:01 +0000 (UTC) Received: from [16.214.83.54] (unknown [16.214.83.54]) by g2t2360.austin.hpecorp.net (Postfix) with ESMTP id AFA7039; Fri, 25 Sep 2020 16:09:59 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Reduce reset vector memory pressure To: devel@edk2.groups.io, lersek@redhat.com, Tom Lendacky Cc: Eric Dong , Ray Ni , Rahul Kumar , Brijesh Singh , Garrett Kirkendall References: <21345cdbc906519558202b3851257ca07b9239ba.1600884239.git.thomas.lendacky@amd.com> From: "Brian J. Johnson" Message-ID: <091b5170-a56c-b1f8-0afe-86444df43e49@hpe.com> Date: Fri, 25 Sep 2020 11:09:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-25_14:2020-09-24,2020-09-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 phishscore=0 spamscore=0 mlxlogscore=853 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009250112 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 9/24/20 1:22 AM, Laszlo Ersek wrote: > - I don't remember if it's required that the APIC ID space be densely > populated. For example, if we have a topology with 7 possible (= > maximum) logical CPUs, I'm unsure if a spec forbids any of those CPUs > from having APIC ID 7. That could cause a problem in > MpInitLibSevEsAPReset(), I assume. FWIW, there are many bare metal processors with non-contiguous APIC IDs. Intel puts the socket ID in the upper bits of the APIC ID. So if the socket doesn't have a power-of-two number of cores, there is always a gap. Plus, the BSP doesn't always have APIC ID 0 -- it depends on which physical cores passed the manufacturing tests for that particular part. That has broken various kernels, BIOSes, and other software at times. So it's best not to make assumptions. I don't know if that applies to VMs, though. The standards may be different (if there are any standards at all in that area.) -- Brian J. Johnson Enterprise X86 Lab Hewlett Packard Enterprise