[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch v6 01/13] docs: libxc migration stream specification
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |