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-ia64-devel

Re: [Xen-ia64-devel] GET_THIS_PADDR appears to be broken

To: tgingold@xxxxxxx
Subject: Re: [Xen-ia64-devel] GET_THIS_PADDR appears to be broken
From: Horms <horms@xxxxxxxxxxxx>
Date: Wed, 27 Jun 2007 22:38:44 +0900
Cc: Yutaka Ezaki <yutaka.ezaki@xxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 27 Jun 2007 06:39:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1182946760.468255c87ae88@xxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070627095955.GA1268@xxxxxxxxxxxx> <1182946760.468255c87ae88@xxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: mutt-ng/devel-r804 (Debian)
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
> ...
> /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.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


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