[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Xen/ia64 presentation
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |