Re: [Patch v6 01/13] docs: libxc migration stream specification

[Andrew Cooper <andrew.cooper3@citrix.com>]

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