Re: [Xen-devel] APIC handling on x86-64

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 03/17/06 6:06 PM >>>
>
>On 17 Mar 2006, at 16:49, Jan Beulich wrote:
>
>> As we had a report of a problem booting Xen on an IBM x460, dying on 
>> the BUG_ON() in init_apic_ldr() in
>> xen/include/asm-x86/mach-summit/mach_apic.h, I started comparing 32- 
>> and 64-bit APIC handling. Quickly I found that the
>> same case is handled gracefully in 64-bits, by just tying any extra 
>> CPUs to the highest bit. (I suppose, will try to
>> verify this with the originator, that the same machine also doesn't 
>> boot with native 32-bit Linux, as the exact same
>> issue should exist there).
>> While doing the same generally shouldn't be a problem, I wonder why 
>> this hasn't been discovered so far and how many
>> else differences there exist.
>
>Differences between i386 and x86/64 native Linux APIC handling? A fair 
>few, although mostly it's because crufty old code has been removed from 
>x86/64. I guess there are occasions where Andi Kleen has improved 
>correctness at the same time as cleaning up. :-)
>
>This is the first time that the strategy of taking latest i386 APIC 
>code has let us down I think.
>
>I guess we just patch it in Xen with a comment explaining the extra 
>diff vs native i386 Linux version of the same file.

Actually, looking further, the originally mentioned adjustment can't work. 
x86-64
Linux can do this because they deliver IPIs (on large systems) in physical
destination mode, and hence they don't really need to values written to DFR and
specifically LDR. Since Xen inherited the 32-bit code, IPIs get sent in logical
(cluster) mode, and then playing games like this with the LDR is only going to
cause problems (you'll hit multiple processors with a send that's intended for a
single one only). Hence I would think that more extensive changes are going to
be needed; entirely taking x86-64's model may not be feasible either (aside of
the fact that this would mean quite extensive code changes), as they don't need
to care about pre-Pentium4 processors.

Jan

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