WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] libxc: remove CPUID core information manglin

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxc: remove CPUID core information mangling
From: Andre Przywara <andre.przywara@xxxxxxx>
Date: Thu, 26 Aug 2010 22:48:57 +0200
Cc: "Huang2, Wei" <Wei.Huang2@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Nitin Kamble <nitin.a.kamble@xxxxxxxxx>
Delivery-date: Thu, 26 Aug 2010 13:50:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C89AFCA6.1F10F%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C89AFCA6.1F10F%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.18 (X11/20081105)
Keir Fraser wrote:
Ah yes, I agree.


On 25/08/2010 16:53, "Huang2, Wei" <Wei.Huang2@xxxxxxx> 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@xxxxxxxxxxxxx]
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" <Wei.Huang2@xxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel