On Thu, Jun 28, 2007 at 05:14:57AM +0200, Tristan Gingold wrote:
> On Thu, Jun 28, 2007 at 05:07:41AM +0200, Tristan Gingold wrote:
> > On Wed, Jun 27, 2007 at 10:38:44PM +0900, Horms wrote:
> > > 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.
> >
> > In fact ar.kr3 is set by SET_PER_CPU_DATA in mca_asm.S
> > Not anymore lost ;-)
>
> and therefore you weren't looking at the correct assignment of kr3!
I'm pretty sure it was the right value, though I'm not sure why.
Perhaps its restored at some stage? When I say that, what I mean is
that I not only does the code work but I get the same value using the
tpa method.
In any case, I agree that the tpa appraoch seems a lot better. I've
played around with it some more and it does indeed seem to work. My
problem was using it in ia64_do_tlb_purge after the DTR PER_CPU_DATA had
been purged.
I'm stull curios to know what problems this might have.
Or in other words why it was changed in efb346a02e70.
In any case, I'll do some more testing and if all goes well
get a patch together shortly.
--
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
|
Home