From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: Re: Xen/ia64 presentation Date: Wed, 27 Apr 2005 15:08:53 -0500 Message-ID: <426FF155.6050608@us.ibm.com> References: <516F50407E01324991DD6D07B0531AD535AFC4@cacexc12.americas.cpqcorp.net> <426FE40C.60102@us.ibm.com> <426FE884.2010904@us.ibm.com> <46747f931d038af6b7606bf02b93c216@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46747f931d038af6b7606bf02b93c216@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Magenheimer, Dan (HP Labs Fort Collins)" , Xen-devel List-Id: xen-devel@lists.xenproject.org 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