[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 > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |