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

[Eduardo Habkost]

On Fri, Nov 29, 2019 at 10:31:36AM +0100, Paolo Bonzini wrote:
> On 28/11/19 17:10, Eduardo Habkost wrote:
> > On Thu, Nov 28, 2019 at 06:15:16PM +0400, Marc-André Lureau wrote:
> >> Hi,
> >>
> >> Setting up shared memory for vhost-user is a bit complicated from
> >> command line, as it requires NUMA setup such as: m 4G -object
> >> memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa
> >> node,memdev=mem.
> >>
> >> Instead, I suggest to add a -mem-shared option for non-numa setups,
> >> that will make the -mem-path or anonymouse memory shareable.
> > 
> > Can we make this be a "-m" option?
> > 
> > Or, even better: can we make "-m" options be automatically
> > translated to memory-backend-* options somehow?
> > 
> 
> 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

-- 
Eduardo