On Wed, Jun 27, 2007 at 05:30:45PM +0200, tgingold@xxxxxxx wrote:
> Quoting Horms <horms@xxxxxxxxxxxx>:
>
> > On Wed, Jun 27, 2007 at 02:19:20PM +0200, tgingold@xxxxxxx wrote:
> > > Quoting Horms <horms@xxxxxxxxxxxx>:
>
> > > 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.
> Strange as ar.kr3 is used by the kernel.
>
> > 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.
> Sure, but as you said:
>
> Previous Solutions
>
> Until 12448:efb346a02e70 there was a tpa based version of
> GET_THIS_PADDR().
>
> #define GET_THIS_PADDR(reg, var) \
> movl reg = THIS_CPU(var) \
> tpa reg = reg
>
> this previous solution avoided the circular dependency.
Yes, I was pondering that after I relplied to you last night.
> I don't remember why this code was changed or why this code doesn't work for
> you.
I'll investigate why this isn't working for me. I suspect it should
and that there is just an error on my part.
I am a little concerned about what problem cased it to be changed in the
first place, perhaps it can't work in an MCA init handler, or is too
dangerous to use there?
--
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