From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: Re: Xen/ia64 presentation Date: Thu, 28 Apr 2005 13:58:38 -0500 Message-ID: <4271325E.9020307@us.ibm.com> References: <516F50407E01324991DD6D07B0531AD535AFC4@cacexc12.americas.cpqcorp.net> <426FE40C.60102@us.ibm.com> <426FE884.2010904@us.ibm.com> <46747f931d038af6b7606bf02b93c216@cl.cam.ac.uk> <426FF155.6050608@us.ibm.com> <768cdb9ef8393197f3d7772291d527c7@cl.cam.ac.uk> <4271271B.2000206@us.ibm.com> <38880a67d18698b906a675852e9a80b1@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: <38880a67d18698b906a675852e9a80b1@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 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