From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US9tk-00059u-2O for qemu-devel@nongnu.org; Tue, 16 Apr 2013 13:42:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1US9ti-0002lx-Hw for qemu-devel@nongnu.org; Tue, 16 Apr 2013 13:42:28 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:50277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1US9ti-0002ln-Ag for qemu-devel@nongnu.org; Tue, 16 Apr 2013 13:42:26 -0400 Received: by mail-lb0-f180.google.com with SMTP id t11so804497lbi.39 for ; Tue, 16 Apr 2013 10:42:25 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1365432230-20028-1-git-send-email-peter.maydell@linaro.org> References: <1365432230-20028-1-git-send-email-peter.maydell@linaro.org> From: Peter Maydell Date: Tue, 16 Apr 2013 18:42:04 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 0/3] target-arm: convert to VMState, fix bugs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paolo Bonzini , Anthony Liguori , patches@linaro.org, Juan Quintela Ping for review -- I plan to put these into a target-arm pullreq at the end of the week if nobody has any review comments. thanks -- PMM On 8 April 2013 15:43, Peter Maydell wrote: > This patch series converts target-arm to doing migration via > a VMState structure, and fixes some minor bugs in migration > of the CPU as well. The bulk of it is a patch Juan sent out > back in the middle of last year > https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00550.html > which I have rebased and messed about with somewhat: > * rebased and fixed conflicts > * updated to use cpu_class_set_vmsd() > * updated with new/removed fields since original patch > * corrected subsection names so vmload doesn't fail > * changed to use custom VMStateInfo for cpsr rather than > presave/postload hooks > > The last of these was the subject of some discussion when Juan > posted the patch (see URL above for the thread). The fundamental > problem that has to be solved is "how do you deal with cases > where the representation in the in memory struct is not the > same as the on the wire representation?": > (a) Juan's original patch does "write wire format to random dummy > field in the struct and then clean things up in presave/postload > hooks". > (b) My patch follows what Alpha, i386 and some devices do: define > a custom VMStateInfo which reads/writes the wire format and > does the conversion to/from the struct. > (c) There was a mooted third approach of defining new vmstate macros > and functionality so you could specify conversion functions for > a field but leave actual reading and writing of the wire format > to the core savevm code. > > The argument against (b) was that it makes introducing a new > migration wire format harder, but on the other hand it's a year > later and nobody has, and we already have examples of this in > tree so another user is no big deal. So it doesn't seem > to me to merit the effort of actually implementing (c). I've > gone for (b) because I think it's better than (a). > > Overall I think the whole series is an improvement over the > separate save/load fields; I'd also like to get this changeover > done before we start having to worry about freezing the ARM > migration format. > > > Juan Quintela (1): > target-arm: port ARM CPU save/load to use VMState > > Peter Maydell (2): > target-arm: Add some missing CPU state fields to VMState > target-arm: Correctly restore FPSCR > > target-arm/cpu-qom.h | 4 + > target-arm/cpu.c | 1 + > target-arm/cpu.h | 2 - > target-arm/machine.c | 430 +++++++++++++++++++++++++------------------------- > 4 files changed, 221 insertions(+), 216 deletions(-) > > -- > 1.7.9.5 > >