Quoting Horms <hor...@verge.net.au>:
GET_THIS_PADDR() doesn't appear to work correclty
on xen-ia64-unstable.hg 15165:96331db61e47
Long-winded description of why
cpu_data = 0xf000000004410000
ia64_tpa(cpu_data) = 0x0000000004410000
__per_cpu_start = 0x0003ffffffff0000
ia64_set_kr(IA64_KR_PER_CPU_DATA,
ia64_tpa(cpu_data) - (long) __per_cpu_start);
ar.k3 = ia64_tpa(cpu_data) - __per_cpu_start;
= 0x0000000004410000 - 0xf000000004410000
= 0x0f00000004420000 # N.B Underflow
I am lost here :-( I though ar.kX were reserved by the domains.
...
...
/home/horms/work/xen/xen-ia64-unstable.hg/xen/arch/ia64/linux-xen/mca_asm.S:271:
relocation truncated to fit: IMM22 against symbol
`per_cpu__ia64_mca_pal_base' defined in .data.percpu section in
/home/horms/work/xen/xen-ia64-unstable.hg/xen/arch/ia64/built_in.o
I'm not really sure what that means, other than that
per_cpu__ia64_mca_pal_base aka THIS_CPU(ia64_mca_pal_base)
ought to be a 22bit integer, which it isn't.
This is the right reason.
I also noticed that the assembled code on xen and linux differ.
Hue, there are data not code!
Tristan.
8 messages in com.xensource.lists.xen-ia64-develRe: [Xen-ia64-devel] GET_THIS_PADDR a...