Re: [Xen-devel] Re: Xen/ia64 presentation

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

Keir Fraser wrote:
> 
> On 27 Apr 2005, at 20:31, Hollis Blanchard wrote:
>>
>> On this subject, I'd also like to ask about full_execution_context_t.
>> execution_context_t is used in a fair number of places in the Xen core;
>> however full_execution_context_t seems to only be used in the dom0
>> interface.
>>
>> The in-Xen analog to full_execution_context_t is arch_exec_domain, with
>> many fields duplicated between the two. Could we consolidate these, or
>> at least give full_execution_context_t a name that better describes its
>> purpose?
> 
> Yes, that's another one that's gross. Maybe rename
> full_execution_context_t to execution_context_t, and rename existing
> execution_context_t to something else (cpu_reg_t, or something like that)?

execution_context_t is also struct xen_regs, so if we like typedefs then
xen_regs_t would be consistent. Right now, lots of code uses xen_regs
and lots uses execution_context_t... should that be made consistent?

xen_regs/execution_context_t seems to mean "state which xen code could
alter", so something to distinguish it from "all CPU state" would be
nice. Maybe something like this:

struct xen_state:  (now xen_regs) state which xen C/asm code could alter
struct vcpu_state: (now exec_domain) all virtual CPU state
struct arch_vcpu_state

("vcpu_regs" might not be good, since we could need to save other
context like software-controlled TLBs, and so "xen_state" would match
"vcpu_state".)

I guess you want to keep a separate virtual CPU struct for the dom0
interface to preserve the ABI? Calling that "execution_context_t" could
work; I don't know what else to call it.

-- 
Hollis Blanchard
IBM Linux Technology Center

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