[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-ia64-devel] GET_THIS_PADDR appears to be broken
On Wed, Jun 27, 2007 at 02:19:20PM +0200, tgingold@xxxxxxx wrote:
> Quoting Horms <horms@xxxxxxxxxxxx>:
> > 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.
I think that is true too.
If my reading of cpu_init() is correct then kX get saved into the
per_cpu variable cpu_kr, which is an array. However it did seem that the
k3 value was sane when I ran my test - no domU present.
However, the question does arise, if kX are unavailable,
then how does assembly code access the physical address of
a per_cpu variable, as if k3 is stashed in a per_cpu variable
there is a circular dependancy.
> > Solution 1
> > 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!
Xen-ia64-devel mailing list