Re: Re: Xen/ia64 presentation

[Hollis Blanchard <hollisb@us.ibm.com>]

Keir Fraser wrote:
> 
> On 28 Apr 2005, at 19:10, Hollis Blanchard wrote:
> 
>> I see you just renamed some structures in the unstable tree... now how
>> about exec_domain? Are we happy with "vcpu_state"?
> 
> The '_state' seems a bit superfluous. How about just 'struct vcpu'?

Sure.

>>> xen_regs/xen_state should probably be entirely arch-specific anyway.
>>> Even now it only pokes through into common code in interrupt-handler
>>> definitions (the final parameter is a xen_regs pointer). It'd be great
>>> to nuke those last few from common code. :-)
>>
>>
>> Yup. I think this could be done by passing 'current' to
>> show_registers(), and let the arch code figure out what to do from
>> there. After I get PPC to a more useful state I will see about the
>> patch, if somebody hasn't beaten me to it...
> 
> 
> I've decided to backtracked on this one. Every architecture will have
> the concept of an interrupted activation, and a stack frame containing
> (at least some of) that activation's state.

Doesn't necessarily have to be on the stack; on PowerPC we are currently
using a separately-allocated piece of memory.

> The pointer passed to IRQ
> handlers is a pointer to that state on the stack. If we do not pass it
> explicitly to the handler then it is very hard to reliably recalculate
> it if it is needed, and it is useful for debugging purposes at the very
> least.

What "debugging purposes"? We've already seen that the only common code
using that type is to pass to (architecture-specific) show_registers().

x86 can get at its state by masking off ESP. PPC can get at it via
'current'. Why then pass a pointer through all interrupt handlers when
none of them care?

> A 'cpu_user_regs' seems like something every arch can provide, right?

PowerPC can, yes.

-- 
Hollis Blanchard
IBM Linux Technology Center