On Wed, Sep 29, 2021 at 10:46:39AM +0100, Richard W.M. Jones wrote:
On Wed, Sep 29, 2021 at 10:33:43AM +0100, Daniel P. Berrangé wrote:
> 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 ?
As far as I can tell no driver has successfully made it upstream,
although there have been a few attempts:
https://lkml.org/lkml/2018/3/1/498
Here's a more recent one from 10 months ago:
https://lore.kernel.org/linux-doc/3E05451B-A9CD-4719-99D0-72750A304044@am...
If I have time I'll patch a Linux kernel with the second patch and see
how it relates to the VMware and KVM parameters, but it probably won't
be today.
I'm not sure if we actually need the full driver or not for testing
purposes. The the GenID is just in memory somewhere, and the somewhere
is reported via ACPI table entry. For QEMU its easy as the data is
exposed via fw_cfg which can be read from sysfs directly without
even needing to look at ACPI entries to find it. Not sure how we
find it with VMWare/HyperV though.
Regards,
Daniel
--
|: