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:10:35 -0500 Message-ID: <4271271B.2000206@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <768cdb9ef8393197f3d7772291d527c7@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: > > x86 Xen makes the distinction between xen_regs and > full_execution_context only because xen_regs is what gets saved on the > stack on entry to / exit from Xen. More advanced state like TLB info > could probably be saved directly into 'struct vcpu_state' where you > detect that you have interrupted a guest activation. Absolutely; I have the same thing in PPC code. I see you just renamed some structures in the unstable tree... now how about exec_domain? Are we happy with "vcpu_state"? > 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... -- Hollis Blanchard IBM Linux Technology Center