[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.
I don't remember why this code was changed or why this code doesn't work for
you.

Tristan.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.