On 07/05/18 18:43, Richard W.M. Jones wrote:
> On Thu, Jul 05, 2018 at 04:20:33PM +0200, Laszlo Ersek wrote:
>> QEMU does the right thing. If other hypervisors don't do this -- while
>> still taking and displaying the value in UUID / GUID textual format --,
>> they are wrong. The VMGENID spec from Microsoft
>> <http://go.microsoft.com/fwlink/?LinkId=260709> specifically mentions
>> "GUID".
>
> The MSFT spec does mention GUID, but it seems to me that it's only
> using GUID as an incidental example -- ie. that you might use the VM
> Generation ID to generate a GUID. Outside that example it
> consistently refers to the VM Gen ID as a 128-bit integer. It also
> says that it could be used as a "high entropy random data source",
> which is not in fact true if it's a UUID.
I don't have additional points regarding whether Microsoft genuinely did
or didn't think of VMGENID in terms of UUID.
However, the fact that the fields of the *original* UUID definition have
been repurposed for fully random bytes is not an argument against. Just
because we nowadays populate all those bytes from a PRNG (sort-of),
thereby ignoring their original field names, we still call the structure
UUID and we still preserve the internal field boundaries. For example,
in UEFI (the spec), we have
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} EFI_GUID;
and in the edk2 codebase, whenever a new GUID is needed for any purpose,
we're supposed to get one by running "uuidgen". From the manual:
There are two types of UUIDs which uuidgen can generate: time-
based UUIDs and random-based UUIDs. By default uuidgen will
generate a random-based UUID if a high-quality random number
generator is present. Otherwise, it will choose a time-based
UUID. It is possible to force the generation of one of these
two UUID types by using the -r or -t options.
> It has to be said that after reading the spec again [the MSFT spec,
> not qemu's spec] and what other hypervisors are doing, I'm not sure
> qemu is doing the right thing here.
That's the thing about specs -- interpretation. I've read the vmgenid
spec several times as well, and I've always understood it as Microsoft
meaning UUID / GUID as a primary representation for VMGENID. I may have
been biased by UUID/GUID usage in UEFI.
When the feature was being developed for QEMU, we struggled with the
interpretation of a good number of other bits as well; hence the
"Requirements" section of QEMU's spec: "this is how we understood it".
Without an open list to discuss things with Microsoft, sometimes we can
only guess what is a "likely faithful" interpretation, and test it in
practice.
I still believe QEMU's current interpretation is the right one; but I
can't prove it.
Laszlo
