From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: Re: [PATCH] libxc: remove CPUID core information mangling Date: Thu, 26 Aug 2010 22:48:57 +0200 Message-ID: <4C76D339.2000909@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Huang2, Wei" , xen-devel , Nitin Kamble List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > Ah yes, I agree. > > > On 25/08/2010 16:53, "Huang2, Wei" wrote: > >> OK. BTW, the old way seems wrong. The correct implementation should be >> (((regs[2] & 0xf000u) >> 12) + 1) << 12. >> >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Wednesday, August 25, 2010 10:39 AM >> To: Huang2, Wei; Przywara, Andre; Nitin Kamble >> Cc: xen-devel >> Subject: Re: [Xen-devel] Re: [PATCH] libxc: remove CPUID core information >> mangling >> >> I meant it should remain the old way, since HVM virtual APIC IDs are >> vcpu_id*2. I agree, that seems to be best way for the time being. Although this value is actually meant to tell different processors apart, so I guess it needs a revisit later. FYI: Real machines use different ways to assign APIC-IDs, for example my 4-way Magny-Cours (4*12 cores) has this: 0x00-0x02: used for I/O-APICs, (could be 4-bit constrained) -0x0f: reserved for IOAPICs 0x10-0x1b: LAPIC-IDs for cores from the 1st processor 0x20-0x2b: LAPIC-IDs for cores from the 2nd processor 0x30-0x3b: LAPIC-IDs for cores from the 3rd processor 0x40-0x4b: LAPIC-IDs for cores from the 4th processor The 80000008:ECX[15:12] value is 4, which means the lower 4 bits of the LAPIC ID indicate the core number within each package. Obviously this scheme does not fit the Xen one's. Thanks Wei for spotting the calculation error! Regards, Andre. >> >> -- Keir >> >> On 25/08/2010 16:28, "Huang2, Wei" wrote: >> >>> Hi Keir, >>> >>> Do you mean that we should leave 80000008:ECX[15:12] as zero or in old way >>> (i.e. (regs[2] & 0xf000u) + 1))? These bits can't be zero, unless we want to >>> use legacy method in multi-core calculation. >>> >>> -Wei >>> >>> ======== >>> I think you shouldn't change handling of 80000008:ECX[15:12] since that does >>> explicitly refer to APIC ID arrangement. The rest of your changes could be >>> correct as far as I can tell from the reference manuals. >>> -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 448-3567-12