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

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

As you may have noticed, Xen/ia64 completely ignores
all of the execution context structs because (as
described in the base for this thread), ia64 can't
represent its state that way.

In fact if you grep for these (as well as xen_regs)
in common files, there are very few uses of them.
And I'd argue that the uses that ARE still in common
(e.g. keyhandler.c, serial/console drivers, dom0_ops)
are places that haven't yet been properly divided between
archdep and common (because Xen/ia64 hacks around them
rather than use them).  Either that or the datatype
is entirely opaque to the routine and is just being
passed along to another (archdep) routine.

In other words, I'm suggesting that perhaps all of
these constructs are archdep and (eventually) shouldn't
appear in common code.

Dan

> -----Original Message-----
> From: Hollis Blanchard [mailto:hollisb@xxxxxxxxxx] 
> Sent: Wednesday, April 27, 2005 2:09 PM
> To: Keir Fraser
> Cc: Xen-devel; Magenheimer, Dan (HP Labs Fort Collins)
> Subject: 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