[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/7][RFC] make xenguest save & restore functions reentrant


  • To: Vincent Hanquez <Vincent.Hanquez@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Sun, 15 Nov 2009 10:20:00 +0000
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 15 Nov 2009 02:20:23 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acpl29b3WDgWaR16S+CVhxxQfKEwNAAAVj6H
  • Thread-topic: [Xen-devel] [PATCH 0/7][RFC] make xenguest save & restore functions reentrant

On 15/11/2009 10:08, "Vincent Hanquez" <Vincent.Hanquez@xxxxxxxxxxxxx>
wrote:

>  agree this isn't pretty. unfortunately i tried the route of changing
> the macro to get from ctx-> but the macro is used also on other files
> xc_core_x86.c and xc_resume.c which use the macro with the guest_width
> and/or p2m_size on the call stack.
> 
> The only other solution I though of, would be to duplicate the value of
> the ex-globals on the stack like:
> ...
> int guest_width = ctx->guest_width;
> int p2m_size = ctx->p2m_size;
> ...
> 
> I decided against, because it might look odd since it doesn't appear
> used and also means I need to track all assignment to this variable.

Another option would be for all users of the macros to have a 'xenguest_ctx'
structure, or whatever you call it. So e.g., in xc_resume:
 struct xenguest_ctx _ctx, *ctx = &_ctx;
 ctx->guest_width = ...
 /* Leave unnecessary/meaningless fields for this caller uninitialised. */

What do you think? The ctx struct can't be that big; we can just ignore
fields that make no sense outside save/restore (i.e., kind of split it into
general-purpose and private/application-specific fields); and it does keep
the macro invocations cleaner.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.