From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [Patch v6 01/13] docs: libxc migration stream specification Date: Tue, 8 Jul 2014 11:48:44 +0100 Message-ID: <53BBCC8C.9080701@citrix.com> References: <1404754682-28379-1-git-send-email-andrew.cooper3@citrix.com> <1404754682-28379-2-git-send-email-andrew.cooper3@citrix.com> <53BBBBA6.6030804@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53BBBBA6.6030804@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel , Xen-devel Cc: Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 08/07/14 10:36, David Vrabel wrote: > On 07/07/14 18:37, Andrew Cooper wrote: >> +SAVING\_CPU >> +---------- >> + >> +A saving cpu record provides a human readable representation of the CPU on >> +which the guest was saved. >> + >> + 0 1 2 3 4 5 6 7 octet >> + +------------------------+------------------------+ >> + | 7bit ASCII String | >> + ... >> + +-------------------------------------------------+ >> + >> +The information is purely informative as it doesn't directly affect how to >> +save or restore the guest, but in the case of an error on restoration may help >> +to narrow down the issue. >> + >> +x86 architecutres use the _CPUID_ 48 character processor brand string. > This is new functionality that I think should be separate from this series. Perhaps. Had I considered that before preparing this latest series, my answer might be different. At this point, it is already merged in and isn't a trivial patch; being the first optional record, there are a number of improvements in the common infrastructure. I don't have the time to maintain a separate patch which modifies core code on top of a series which introduces that code code, which is still under development and change. If the underlying series were static, the situation would be very different. > > This feels like something that should be machine readable and verifiable > rather than a human readable string. > > That's not to say a freeform record for human readable information > wouldn't be useful, but I don't think it should be restricted to just > the CPU name. What else would you include? There are plenty of other optional records available. I put this in specifically to help identify the case where someone suspended a VM in an AMD server and attempted to resume it at some point later on an Intel server. Presently, the results of attempting this are particularly cryptic, with hvm_set_context failing with EPERM. > > 7 bit ASCII is rather quaint. Would utf-8 be better? > > David > 7bit ASCII is far easier to deal with in a C program without linking a UTF library into libxc. As it stands, this is a valid utf-8 string. ~Andrew