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
