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

["Michael S. Tsirkin" <mst@redhat.com>]

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 <nikita.leshchenko@oracle.com>
> > > Signed-off-by: Liran Alon <liran.alon@oracle.com>
> > 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