Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 16:39, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 04:24:45PM +0200, Liran Alon wrote: Re-thinking about this... QEMU VMPort interface was quite broken already (See first patch in series "hw/i386/vmport: Propagate IOPort read to vCPU EAX register"). The introduction of that fix already changes the result of all existing commands from guest perspective which relied on return-value from vmport_ioport_read(). E.g. CMD_GETVERSION and CMD_GETRAMSIZE. In theory, we should have also made that bug-fix be tied to machine-type. To similarly avoid the issue of migrating a VM from a working VMPort command implementation to a non-working one. i.e. In case of migrating from new QEMU to old QEMU. Do we wish to create a property-flag for that fix as-well? Yes, I meants that too. Just include everything in the same property. It ugly the code with a lot of "if"s for maintaining compatibility for guests that somehow relies on interface being broken and unusable. Can do this but am wondering if it's worth it. Or can we just drop all the machine-type flags alltogether (Including the suggested "commands-v2") and declare this the first actually working VMPort implementation? -Liran It's hard to be sure no one used this Well... Both implemented commands (CMD_GETVERSION and CMD_GETRRAMSIZE) fails to return their proper value. CMD_GETVERSION will always return VMPORT_MAGIC that happened to be in EAX previously (i.e. return 0x564D5868 instead of 6). CMD_GETRAMSIZE will always return VMPORT_MAGIC that happened to be in EAX previously (i.e. return 0x564D5868 instead of VM RAM size). If guest somehow relied on this, it is already quite broken... My belief is that all upstream QEMU users today relies on VMPort only for the sake of a functioning VMMouse which is indeed not broken because vmmouse_set_data() explicitly override EAX. , and the overhead isn't big. But that would be a maintainer call. In any case you need to call this out explicitly in the commit log, and I guess block migration for old machine types. Blocking migration for old machine-types is a "no go" in my opinion as vmport is enabled by default. It will cause too many VMs to need be able to backwards migrate. So it's either doing nothing (as patch-series is now) or adding a flag that adds a bunch of ugly "ifs" and is tied to a machine-type. -Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 04:24:45PM +0200, Liran Alon wrote: > > On 10/03/2020 13:22, Michael S. Tsirkin wrote: > > On Tue, Mar 10, 2020 at 01:13:21PM +0200, Liran Alon wrote: > > > On 10/03/2020 11:34, Michael S. Tsirkin wrote: > > > > On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote: > > > > > This is VMware documented functionallity that some guests rely on. > > > > > Returns the BIOS UUID of the current virtual machine. > > > > > > > > > > Reviewed-by: Nikita Leshenko > > > > > Signed-off-by: Liran Alon > > > > So this at least seems guest-visible. > > > > > > > > So I suspect you need to add properties to > > > > disable this for old machine types, to avoid > > > > breaking compatibility with live-migration. > > > It is indeed guest visible. > > > In theory, you are right that for every guest-visible change, we should > > > make > > > sure to expose it to only new machine-types. > > > > > > However, in this case, I feel it just unnecessary over-complicates the > > > code. > > > I don't see how a guest which previously failed to use this command, will > > > fail because after Live-Migration it could succeed. > > The reverse can happen, start guest on a new qemu, command seems to > > work, then we migrate and it fails. > > > > And I guess this applies to the version right? > > > > > If you insist, I will add such functionality. In that case, do you think a > > > single flag will suffice for the addition of all new commands > > > (i.e. "commands-version" that it's number specifies set of commands to > > > expose), or you want to have a per-command flag? > > > > > > -Liran > > Can be a single flag but I'd just do it a boolean that enables a group > > of commands. E.g. "commands-v2". > > > Re-thinking about this... > > QEMU VMPort interface was quite broken already (See first patch in series > "hw/i386/vmport: Propagate IOPort read to vCPU EAX register"). > The introduction of that fix already changes the result of all existing > commands from guest perspective which relied on return-value from > vmport_ioport_read(). > E.g. CMD_GETVERSION and CMD_GETRAMSIZE. > > In theory, we should have also made that bug-fix be tied to machine-type. To > similarly avoid the issue of migrating a VM from a working VMPort command > implementation to a non-working one. > i.e. In case of migrating from new QEMU to old QEMU. Do we wish to create a > property-flag for that fix as-well? Yes, I meants that too. Just include everything in the same property. > Or can we just drop all the machine-type > flags alltogether (Including the suggested "commands-v2") > and declare this the first actually working VMPort implementation? > > -Liran It's hard to be sure no one used this, and the overhead isn't big. But that would be a maintainer call. In any case you need to call this out explicitly in the commit log, and I guess block migration for old machine types.
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 13:22, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 01:13:21PM +0200, Liran Alon wrote: On 10/03/2020 11:34, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote: This is VMware documented functionallity that some guests rely on. Returns the BIOS UUID of the current virtual machine. Reviewed-by: Nikita Leshenko Signed-off-by: Liran Alon So this at least seems guest-visible. So I suspect you need to add properties to disable this for old machine types, to avoid breaking compatibility with live-migration. It is indeed guest visible. In theory, you are right that for every guest-visible change, we should make sure to expose it to only new machine-types. However, in this case, I feel it just unnecessary over-complicates the code. I don't see how a guest which previously failed to use this command, will fail because after Live-Migration it could succeed. The reverse can happen, start guest on a new qemu, command seems to work, then we migrate and it fails. And I guess this applies to the version right? If you insist, I will add such functionality. In that case, do you think a single flag will suffice for the addition of all new commands (i.e. "commands-version" that it's number specifies set of commands to expose), or you want to have a per-command flag? -Liran Can be a single flag but I'd just do it a boolean that enables a group of commands. E.g. "commands-v2". Re-thinking about this... QEMU VMPort interface was quite broken already (See first patch in series "hw/i386/vmport: Propagate IOPort read to vCPU EAX register"). The introduction of that fix already changes the result of all existing commands from guest perspective which relied on return-value from vmport_ioport_read(). E.g. CMD_GETVERSION and CMD_GETRAMSIZE. In theory, we should have also made that bug-fix be tied to machine-type. To similarly avoid the issue of migrating a VM from a working VMPort command implementation to a non-working one. i.e. In case of migrating from new QEMU to old QEMU. Do we wish to create a property-flag for that fix as-well? Or can we just drop all the machine-type flags alltogether (Including the suggested "commands-v2") and declare this the first actually working VMPort implementation? -Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 02:37:07PM +0200, Liran Alon wrote: > So I think you are right this should be le32_to_cpu(). i.e. Treat the > uuid_part[x] as little-endian and convert it to native CPU format. > > I always get confused in this :) > > Thanks, > -Liran Yes - Linux has tagging for this so one knows what's going on, and sparse can catch errors. Unfortunately QEMU does not use this capability. A nice (not so little) project for someone :) -- MST
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 14:01, Michael S. Tsirkin wrote:
On Tue, Mar 10, 2020 at 04:44:54AM -0700, Liran Alon wrote:
On 10/03/2020 11:22, Michael S. Tsirkin wrote:
On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
This is VMware documented functionallity that some guests rely on.
Returns the BIOS UUID of the current virtual machine.
Reviewed-by: Nikita Leshenko
Signed-off-by: Liran Alon
---
hw/i386/vmport.c | 14 ++
include/hw/i386/pc.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 2ae5afc42b50..7687f3368a55 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -26,6 +26,7 @@
#include "hw/i386/pc.h"
#include "hw/input/i8042.h"
#include "hw/qdev-properties.h"
+#include "sysemu/sysemu.h"
#include "sysemu/hw_accel.h"
#include "qemu/log.h"
#include "trace.h"
@@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque,
uint32_t addr)
return port_state->vmx_version;
}
+static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
+{
+X86CPU *cpu = X86_CPU(current_cpu);
+uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);
BTW missing space before * here.
Yes. I'm fixing this in v2. So the Patchew bot email.
+
+cpu->env.regs[R_EAX] = uuid_parts[0];
+cpu->env.regs[R_EBX] = uuid_parts[1];
+cpu->env.regs[R_ECX] = uuid_parts[2];
+cpu->env.regs[R_EDX] = uuid_parts[3];
+return cpu->env.regs[R_EAX];
+}
+
Should be LE here?
No. This is how the UUID is expected to be returned to guest.
-Liran
Um *how* is it expected to be returned? IIUC this takes network order
byte data and handles it as host endian. Assuming it's right on an LE
host it isn't on a BE host. So I am guessing you want le32_to_cpu here.
Oh I see. Because you say this code can also executes on a BE host using
TCG.
qemu_uuid.data is in the byte order specified by RFC4122, which is
indeed network-order.
The byte order of each register should be LE (As in x86 host).
E,g. For VMware's uuid.bios = " 56 4d 3e 7a 92 ee 4c 46-e8 0d 86 f3 68
a0 cb e7", this should return:
EAX: 7a3e4d56
EBX: 464cee92
ECX: f3860de8
EDX: e7cba068
So I think you are right this should be le32_to_cpu(). i.e. Treat the
uuid_part[x] as little-endian and convert it to native CPU format.
I always get confused in this :)
Thanks,
-Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 04:44:54AM -0700, Liran Alon wrote:
>
> On 10/03/2020 11:22, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
> > > This is VMware documented functionallity that some guests rely on.
> > > Returns the BIOS UUID of the current virtual machine.
> > >
> > > Reviewed-by: Nikita Leshenko
> > > Signed-off-by: Liran Alon
> > > ---
> > > hw/i386/vmport.c | 14 ++
> > > include/hw/i386/pc.h | 1 +
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
> > > index 2ae5afc42b50..7687f3368a55 100644
> > > --- a/hw/i386/vmport.c
> > > +++ b/hw/i386/vmport.c
> > > @@ -26,6 +26,7 @@
> > > #include "hw/i386/pc.h"
> > > #include "hw/input/i8042.h"
> > > #include "hw/qdev-properties.h"
> > > +#include "sysemu/sysemu.h"
> > > #include "sysemu/hw_accel.h"
> > > #include "qemu/log.h"
> > > #include "trace.h"
> > > @@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque,
> > > uint32_t addr)
> > > return port_state->vmx_version;
> > > }
> > > +static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
> > > +{
> > > +X86CPU *cpu = X86_CPU(current_cpu);
> > > +uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);
BTW missing space before * here.
> > > +
> > > +cpu->env.regs[R_EAX] = uuid_parts[0];
> > > +cpu->env.regs[R_EBX] = uuid_parts[1];
> > > +cpu->env.regs[R_ECX] = uuid_parts[2];
> > > +cpu->env.regs[R_EDX] = uuid_parts[3];
> > > +return cpu->env.regs[R_EAX];
> > > +}
> > > +
> > Should be LE here?
>
> No. This is how the UUID is expected to be returned to guest.
>
> -Liran
>
Um *how* is it expected to be returned? IIUC this takes network order
byte data and handles it as host endian. Assuming it's right on an LE
host it isn't on a BE host. So I am guessing you want le32_to_cpu here.
--
MST
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 11:22, Michael S. Tsirkin wrote:
On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
This is VMware documented functionallity that some guests rely on.
Returns the BIOS UUID of the current virtual machine.
Reviewed-by: Nikita Leshenko
Signed-off-by: Liran Alon
---
hw/i386/vmport.c | 14 ++
include/hw/i386/pc.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
index 2ae5afc42b50..7687f3368a55 100644
--- a/hw/i386/vmport.c
+++ b/hw/i386/vmport.c
@@ -26,6 +26,7 @@
#include "hw/i386/pc.h"
#include "hw/input/i8042.h"
#include "hw/qdev-properties.h"
+#include "sysemu/sysemu.h"
#include "sysemu/hw_accel.h"
#include "qemu/log.h"
#include "trace.h"
@@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque,
uint32_t addr)
return port_state->vmx_version;
}
+static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
+{
+X86CPU *cpu = X86_CPU(current_cpu);
+uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);
+
+cpu->env.regs[R_EAX] = uuid_parts[0];
+cpu->env.regs[R_EBX] = uuid_parts[1];
+cpu->env.regs[R_ECX] = uuid_parts[2];
+cpu->env.regs[R_EDX] = uuid_parts[3];
+return cpu->env.regs[R_EAX];
+}
+
Should be LE here?
No. This is how the UUID is expected to be returned to guest.
-Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 13:22, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 01:13:21PM +0200, Liran Alon wrote: On 10/03/2020 11:34, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote: This is VMware documented functionallity that some guests rely on. Returns the BIOS UUID of the current virtual machine. Reviewed-by: Nikita Leshenko Signed-off-by: Liran Alon So this at least seems guest-visible. So I suspect you need to add properties to disable this for old machine types, to avoid breaking compatibility with live-migration. It is indeed guest visible. In theory, you are right that for every guest-visible change, we should make sure to expose it to only new machine-types. However, in this case, I feel it just unnecessary over-complicates the code. I don't see how a guest which previously failed to use this command, will fail because after Live-Migration it could succeed. The reverse can happen, start guest on a new qemu, command seems to work, then we migrate and it fails. And I guess this applies to the version right? Hmm good point. For backwards migration this could indeed be an issue. Making the existence of these commands tied to machine-type should suffice. Regarding vmx-version, because we haven't changed it yet (only created property), we should be fine. On first patch that changes it, we need to tie it to machine-type as-well. If you insist, I will add such functionality. In that case, do you think a single flag will suffice for the addition of all new commands (i.e. "commands-version" that it's number specifies set of commands to expose), or you want to have a per-command flag? -Liran Can be a single flag but I'd just do it a boolean that enables a group of commands. E.g. "commands-v2". Ok. Will do. Thanks, -Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 01:13:21PM +0200, Liran Alon wrote: > > On 10/03/2020 11:34, Michael S. Tsirkin wrote: > > On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote: > > > This is VMware documented functionallity that some guests rely on. > > > Returns the BIOS UUID of the current virtual machine. > > > > > > Reviewed-by: Nikita Leshenko > > > Signed-off-by: Liran Alon > > So this at least seems guest-visible. > > > > So I suspect you need to add properties to > > disable this for old machine types, to avoid > > breaking compatibility with live-migration. > > It is indeed guest visible. > In theory, you are right that for every guest-visible change, we should make > sure to expose it to only new machine-types. > > However, in this case, I feel it just unnecessary over-complicates the code. > I don't see how a guest which previously failed to use this command, will > fail because after Live-Migration it could succeed. The reverse can happen, start guest on a new qemu, command seems to work, then we migrate and it fails. And I guess this applies to the version right? > If you insist, I will add such functionality. In that case, do you think a > single flag will suffice for the addition of all new commands > (i.e. "commands-version" that it's number specifies set of commands to > expose), or you want to have a per-command flag? > > -Liran Can be a single flag but I'd just do it a boolean that enables a group of commands. E.g. "commands-v2". -- MST
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On 10/03/2020 11:34, Michael S. Tsirkin wrote: On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote: This is VMware documented functionallity that some guests rely on. Returns the BIOS UUID of the current virtual machine. Reviewed-by: Nikita Leshenko Signed-off-by: Liran Alon So this at least seems guest-visible. So I suspect you need to add properties to disable this for old machine types, to avoid breaking compatibility with live-migration. It is indeed guest visible. In theory, you are right that for every guest-visible change, we should make sure to expose it to only new machine-types. However, in this case, I feel it just unnecessary over-complicates the code. I don't see how a guest which previously failed to use this command, will fail because after Live-Migration it could succeed. If you insist, I will add such functionality. In that case, do you think a single flag will suffice for the addition of all new commands (i.e. "commands-version" that it's number specifies set of commands to expose), or you want to have a per-command flag? -Liran
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
> This is VMware documented functionallity that some guests rely on.
> Returns the BIOS UUID of the current virtual machine.
>
> Reviewed-by: Nikita Leshenko
> Signed-off-by: Liran Alon
So this at least seems guest-visible.
So I suspect you need to add properties to
disable this for old machine types, to avoid
breaking compatibility with live-migration.
> ---
> hw/i386/vmport.c | 14 ++
> include/hw/i386/pc.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
> index 2ae5afc42b50..7687f3368a55 100644
> --- a/hw/i386/vmport.c
> +++ b/hw/i386/vmport.c
> @@ -26,6 +26,7 @@
> #include "hw/i386/pc.h"
> #include "hw/input/i8042.h"
> #include "hw/qdev-properties.h"
> +#include "sysemu/sysemu.h"
> #include "sysemu/hw_accel.h"
> #include "qemu/log.h"
> #include "trace.h"
> @@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque,
> uint32_t addr)
> return port_state->vmx_version;
> }
>
> +static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
> +{
> +X86CPU *cpu = X86_CPU(current_cpu);
> +uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);
> +
> +cpu->env.regs[R_EAX] = uuid_parts[0];
> +cpu->env.regs[R_EBX] = uuid_parts[1];
> +cpu->env.regs[R_ECX] = uuid_parts[2];
> +cpu->env.regs[R_EDX] = uuid_parts[3];
> +return cpu->env.regs[R_EAX];
> +}
> +
> static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
> {
> X86CPU *cpu = X86_CPU(current_cpu);
> @@ -171,6 +184,7 @@ static void vmport_realizefn(DeviceState *dev, Error
> **errp)
> port_state = s;
> /* Register some generic port commands */
> vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
> +vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
> vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
> }
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 7f15a01137b1..ea87eb93511e 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -140,6 +140,7 @@ typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t
> address);
>
> typedef enum {
> VMPORT_CMD_GETVERSION = 10,
> +VMPORT_CMD_GETBIOSUUID = 19,
> VMPORT_CMD_GETRAMSIZE = 20,
> VMPORT_CMD_VMMOUSE_DATA = 39,
> VMPORT_CMD_VMMOUSE_STATUS = 40,
> --
> 2.20.1
Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
On Tue, Mar 10, 2020 at 01:54:04AM +0200, Liran Alon wrote:
> This is VMware documented functionallity that some guests rely on.
> Returns the BIOS UUID of the current virtual machine.
>
> Reviewed-by: Nikita Leshenko
> Signed-off-by: Liran Alon
> ---
> hw/i386/vmport.c | 14 ++
> include/hw/i386/pc.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
> index 2ae5afc42b50..7687f3368a55 100644
> --- a/hw/i386/vmport.c
> +++ b/hw/i386/vmport.c
> @@ -26,6 +26,7 @@
> #include "hw/i386/pc.h"
> #include "hw/input/i8042.h"
> #include "hw/qdev-properties.h"
> +#include "sysemu/sysemu.h"
> #include "sysemu/hw_accel.h"
> #include "qemu/log.h"
> #include "trace.h"
> @@ -121,6 +122,18 @@ static uint32_t vmport_cmd_get_version(void *opaque,
> uint32_t addr)
> return port_state->vmx_version;
> }
>
> +static uint32_t vmport_cmd_get_bios_uuid(void *opaque, uint32_t addr)
> +{
> +X86CPU *cpu = X86_CPU(current_cpu);
> +uint32_t *uuid_parts = (uint32_t*)(qemu_uuid.data);
> +
> +cpu->env.regs[R_EAX] = uuid_parts[0];
> +cpu->env.regs[R_EBX] = uuid_parts[1];
> +cpu->env.regs[R_ECX] = uuid_parts[2];
> +cpu->env.regs[R_EDX] = uuid_parts[3];
> +return cpu->env.regs[R_EAX];
> +}
> +
Should be LE here?
> static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
> {
> X86CPU *cpu = X86_CPU(current_cpu);
> @@ -171,6 +184,7 @@ static void vmport_realizefn(DeviceState *dev, Error
> **errp)
> port_state = s;
> /* Register some generic port commands */
> vmport_register(VMPORT_CMD_GETVERSION, vmport_cmd_get_version, NULL);
> +vmport_register(VMPORT_CMD_GETBIOSUUID, vmport_cmd_get_bios_uuid, NULL);
> vmport_register(VMPORT_CMD_GETRAMSIZE, vmport_cmd_ram_size, NULL);
> }
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 7f15a01137b1..ea87eb93511e 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -140,6 +140,7 @@ typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t
> address);
>
> typedef enum {
> VMPORT_CMD_GETVERSION = 10,
> +VMPORT_CMD_GETBIOSUUID = 19,
> VMPORT_CMD_GETRAMSIZE = 20,
> VMPORT_CMD_VMMOUSE_DATA = 39,
> VMPORT_CMD_VMMOUSE_STATUS = 40,
> --
> 2.20.1
