From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=KP9F=OT=nongnu.org=qemu-devel-bounces+qemu-devel=archiver.kernel.org@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id B5670C433F5
	for <qemu-devel@archiver.kernel.org>; Wed, 29 Sep 2021 10:05:05 +0000 (UTC)
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 4FAF6613CD
	for <qemu-devel@archiver.kernel.org>; Wed, 29 Sep 2021 10:05:05 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4FAF6613CD
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org
Received: from localhost ([::1]:50624 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org>)
	id 1mVWSW-00087o-Fw
	for qemu-devel@archiver.kernel.org; Wed, 29 Sep 2021 06:05:04 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:45906)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <berrange@redhat.com>)
 id 1mVVyM-0008Mu-EF
 for qemu-devel@nongnu.org; Wed, 29 Sep 2021 05:33:54 -0400
Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:29857)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <berrange@redhat.com>)
 id 1mVVyK-0001NU-8E
 for qemu-devel@nongnu.org; Wed, 29 Sep 2021 05:33:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1632908031;
 h=from:from:reply-to:reply-to:subject:subject:date:date:
 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
 content-type:content-type:in-reply-to:in-reply-to:  references:references;
 bh=Xd1S47yaULQk1//gZ0TBgJMITrtI0Bly66VEHEg5e/0=;
 b=EuxJeN8tvJRWq3XUJGh2L2MpC5omFJtk01QkXuCkph+PzZTtK5OBXvoBI7VkZUbZ3UdS27
 uh3Z6OWOHeotrbMYmX2CXt6B5g8eID+K8sgiH5KjK46ZUwu/nPkoFYkJueYT9je3Aa38PD
 VsQeTS6aOjnmVvpcdtchlrwKpoIigzU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-244-wWcetfNePp2apTzgbqoi8Q-1; Wed, 29 Sep 2021 05:33:49 -0400
X-MC-Unique: wWcetfNePp2apTzgbqoi8Q-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1F8608015C7
 for <qemu-devel@nongnu.org>; Wed, 29 Sep 2021 09:33:49 +0000 (UTC)
Received: from redhat.com (unknown [10.39.192.82])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id A3C3460C81;
 Wed, 29 Sep 2021 09:33:47 +0000 (UTC)
Date: Wed, 29 Sep 2021 10:33:43 +0100
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Subject: Re: [PATCH 0/1] vmx: Fix <genid/> mapping
Message-ID: <YVQy9yiU1RPxCcM8@redhat.com>
References: <cover.1632900578.git.mprivozn@redhat.com>
 <20210929092044.GE3361@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20210929092044.GE3361@redhat.com>
User-Agent: Mutt/2.0.7 (2021-05-04)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
Authentication-Results: relay.mimecast.com;
 auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com;
 helo=us-smtp-delivery-124.mimecast.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: qemu-devel@nongnu.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
 <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <https://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
 <mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
Cc: libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
 qemu-devel@nongnu.org
Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org
Sender: "Qemu-devel"
 <qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org>

On Wed, Sep 29, 2021 at 10:20:44AM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote:
> > Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
> > was brought up in a private thread that libvirt doesn't report correct
> > UUIDs. For instance for the following input:
> > 
> >   vm.genid = "-8536691797830587195"
> >   vm.genidX = "-1723453263670062919"
> 
> (The two lines above come from a VMware .vmx file)
> 
> The only thing that really matters is what the guest sees.  I ran
> VMGENID.EXE (https://bugzilla.redhat.com/show_bug.cgi?id=1598350#c3
> https://docs.microsoft.com/en-gb/windows/win32/hyperv_v2/virtual-machine-generation-identifier)
> inside the guest and it showed:
> 
>   8987940a09512cc5:e81510634ff550b9
> 
> Note these numbers are the hex equivalents of the VMware .vmx numbers:
> 
> >>> print("%x" % (2**64-8536691797830587195))
> 8987940a09512cc5
> >>> print("%x" % (2**64-1723453263670062919))
> e81510634ff550b9
> 
> > Libvirt would report:
> > 
> >   <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid>
> > 
> > while virt-v2v would report:
> > 
> >   <genid>09512cc5-940a-8987-b950-f54f631015e8</genid>
> 
> After thinking about this a bit more, IMHO the real problem is
> with qemu.  If you pass this to qemu:
> 
>   -device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0
> 
> then inside the guest VMGENID shows 2cc509518987940a:b950f54f631015e8 (wrong)
> 
> If you pass this to qemu:
> 
>   ...guid=09512cc5-940a-8987-b950-f54f631015e8...
> 
> then inside the guest it sees 8987940a09512cc5:e81510634ff550b9
> (the correct values, matching VMware).
> 
> This is the reason why virt-v2v mangles the GUID, in order to trick
> libvirt into passing a mangled GUID which gets mangled again by qemu
> which is the same as unmangling it.
> 
> So another way to fix this could be for us to fix qemu.  We could just
> pass the two numbers to qemu instead of using GUIDs, eg:
> 
>   -device vmgenid,low=0x8987940a09512cc5,high=0xe81510634ff550b9,id=vmgenid0
> 
> and then we'd fix the implementation in qemu so that the low/high
> values match what is seen by VMGENID.EXE in the guest.
> 
> Or we could have libvirt use the current GUID in <genid> but to do the
> mangling when it gets passed through to qemu (instead of virt-v2v
> doing the mangling).

On the libvirt side, the #1 most important thing is that a given
XML string

  <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid>

results in the same value being exposed to the guest OS, for both
the QEMU and VMWare drivers.  Whehter the guest sees the bytes in
the same order is not essential, but it would be less of a surprise
if it did match.

Ultimately as long as the mapping from libvirt XML to guest visible
string is consistent across drivers, that's sufficient.

> Adding qemu-devel because I'm interesting to see if the qemu
> developers would prefer to fix this properly in qemu.

No matter what order QEMU accepts the data in, it can be said to be
functionally correct. If the order is "unusual" though, it ought to
at least be documented how the QEMU order corresponds to guest visible
order.

Incidentally I wonder how much to trust VMGENID.EXE and whether that
actally reports what it gets out of guest memory "as is", or whether
it has done any byte re-ordering.

I'm curious what Linux kernel sees for the genid on Vmware vs KVM
hosts, as probably I'd trust that data more ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|