[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 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
> #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
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?
Xen-ia64-devel mailing list