Re: [RFC PATCH 01/13] machine: Add mirrorvcpus=N suboption to -smp

[Eric Blake <eblake@redhat.com>]

On Mon, Aug 16, 2021 at 01:26:45PM +0000, Ashish Kalra wrote:
> From: Dov Murik <dovmurik@linux.vnet.ibm.com>
> 
> Add a notion of mirror vcpus to CpuTopology, which will allow to
> designate a few vcpus (normally 1) for running the guest
> migration handler (MH).
> 
> Example usage for starting a 4-vcpu guest, of which 1 vcpu is marked as
> mirror vcpu.
> 
>     qemu-system-x86_64 -smp 4,mirrorvcpus=1 ...
> 
> Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
> Co-developed-by: Ashish Kalra <ashish.kalra@amd.com>
> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> ---

> +++ b/qapi/machine.json
> @@ -1303,6 +1303,8 @@
>  #
>  # @maxcpus: maximum number of hotpluggable virtual CPUs in the virtual machine
>  #
> +# @mirrorvcpus: maximum number of mirror virtual CPUs in the virtual machine
> +#

Needs a '(since 6.2)' tag.

>  # Since: 6.1
>  ##
>  { 'struct': 'SMPConfiguration', 'data': {
> @@ -1311,4 +1313,5 @@
>       '*dies': 'int',
>       '*cores': 'int',
>       '*threads': 'int',
> -     '*maxcpus': 'int' } }
> +     '*maxcpus': 'int',
> +     '*mirrorvcpus': 'int' } }

Is this really the right place to be adding it?  The rest of this
struct feels like things that advertise what bare metal can do, and
therefore what we are emulating.  But bare metal can't do mirrors -
that's something that is completely in the realm of emulation only.
If I understand the cover letter, the guest shouldn't be able to
detect that mirroring exists, which is different from how the guest
DOES detect how many dies, cores, and threads are available to use.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org