[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID

From: Liran Alon
Subject: Re: [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID
Date: Tue, 10 Mar 2020 13:35:26 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

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 <address@hidden>
Signed-off-by: Liran Alon <address@hidden>
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?

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]