From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 666C1DDEF1 for ; Thu, 5 Feb 2009 14:30:12 +1100 (EST) Message-ID: <498A5D38.9030009@cs.columbia.edu> Date: Wed, 04 Feb 2009 22:30:00 -0500 From: Oren Laadan MIME-Version: 1.0 To: Benjamin Herrenschmidt Subject: Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation References: <1233182478-27113-1-git-send-email-ntl@pobox.com> <1233182478-27113-2-git-send-email-ntl@pobox.com> <1233718789.16867.156.camel@pasglop> <20090204155406.GA2039@us.ibm.com> <1233781099.4612.1.camel@pasglop> <498A284E.4050501@cs.columbia.edu> <1233793012.4612.32.camel@pasglop> In-Reply-To: <1233793012.4612.32.camel@pasglop> Content-Type: text/plain; charset=ISO-8859-1 Cc: containers@lists.osdl.org, "Serge E. Hallyn" , Nathan Lynch , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Benjamin Herrenschmidt wrote: > On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote: >> * Anything that is decided at compiled time should probably go to the arch- >> dependent header. >> >> * Anything that can change at boot time (e.g., for x86 that would include >> the capabilities of the FPU), or even run time (is there any ?) should >> be described to the letter (in fine print) in 'struct cr_hdr_cpu' and >> friends. > > I think we should avoid compile time completely. For instance, TASK_COMM_LEN is currently defined as 16; but in future (or custom) kernel it may be different; so in the task header I put a field that explicitly indicates this length, just in case. I think it's useful to be able to detect such inconsistencies. (of course this example is not arch-specific; and it would be wiser to have one such entry for the entire checkpoint image instead of one for each process) I concur with the rest below. Oren > > We mostly try to have kernels running on everything anyway, and there's > no reason not to be able to move a snapshot to a different CPU if it's > not using a feature of the CPU that is different. > > Nathan, what about you start the structure with a 64 bit bitmask that > indicates what "records" are present followed by concatenated records ? > > IE. The "main" state (pt_regs) wouldn't change, but then, you could have > a list of things: > > - FPRs > - old style VSX > - VSRs > - Freescale SPE state > - DABR > - BookE IAC/DACs > - tbd... > > Then, when resuming a snapshot, we can use some bit masks trickery > indicating the validity on a given target. IE. If CPU has no VSX and > original program uses VSX then you can't resume. But if CPU has VSR you > can.. etc... We can keep it trivial at fist, especting the same > features, and try to be smart later. > > Ben. > > >