Re: [PATCH 0/2] RFC: add -mem-shared option

[Paolo Bonzini]

On 01/12/19 16:40, Marc-André Lureau wrote:
>>> The original idea was to always support one NUMA node, so that you could
>>> do "-numa node,memdev=..." to specify a memory backend with -object.
>>> However, this is not possible anymore since
>>>
>>>     if (!mc->cpu_index_to_instance_props ||
>>>         !mc->get_default_cpu_node_id) {
>>>         error_setg(errp, "NUMA is not supported by this machine-type");
>>>         return;
>>>     }
>>>
>>> has been added to hw/core/numa.c.
>>>
>>> Therefore, I think instead of -mem-shared we should add a "-m
>>> memdev=..." option.  This option:
>>>
>>> * would be mutually exclusive with both -mem-path
>>>
>>> * would be handled from allocate_system_memory_nonnuma.
>>>
>>> * could be mutually exclusive "-numa node", or could just be mutually
>>> exclusive with "-numa node,memdev=..." (the logical conclusion of that
>>> however would be an undeprecation of "-numa node,mem=...", so that has
>>> to be taken into account as well).
>> I completely agree we could do this.  I just think this misses
>> completely the point of this series, because usability of:
>>
>>   -object memory-backend-file,...,share=on,id=mem -m ...,memdev=mem
>>
>> is not much better than the usability of:
>>
>>   -object memory-backend-file,...,share=on,id=mem -numa node,memdev=mem
>>
> +1
> Perhaps when all RAM allocation will occur through memory-backend,
> "-mem-shared" could be simply an alias to "-global
> memory-backend.shared=on"

Yes, this is the point.  There are two parts in this series:

(1) allowing use of vhost-user on non-NUMA machines

(2) providing syntactic sugar for it

I have no problem with -mem-shared for (2), but it should just be
syntactic sugar for (1).  It's okay if -mem-shared is a global variable
rather than an alias for -global; the important part is not to add any
feature that is not available from the QOM-style command line options.

Paolo