On Fri, 29 Nov 2019 11:11:09 +0100
Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 29/11/19 11:07, Igor Mammedov wrote:
> >>> So user who wants something non trivial could override default
> >>> non-numa behavior with
> >>> -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
> >>> -machine memdev=mem
> >>> or use any other backend that suits theirs needs.
> >> That's nice, but not as friendly as a simple -mem-shared.
> > (I still do not like idea of convenience options but it won't
> > get onto the way much if implemented as "global property" to memdev,
> > so I won't object if there is real demand for it)
>
> I agree with Igor, we should always think about the generic ("object
> model") options and only then add convenience option.
>
> It looks like the remaining point is to decide between "-m memdev" and
> "-machine memdev".
I'm still entertaining idea, to use -device pc-dimm|some_ram_dev
for main RAM but that's not generic enough so I'd probably post
'-machine memdev' variant for now and think some more on -device
(we can add front-end re-factoring if necessary on top).
As for "-m", I'd make it just an alias that translates
-m/mem-path/mem-prealloc
combination to appropriate '-object' for '-machine memdev' consumption.
That should cover compat purposes for old machines and the rest of
-m options (maxmem/slots) would be aliased to appropriate machine options.
That will allow us to get rid of ad-hoc '-m' parser. After that it would
be possible to deprecate '-m' in favor of machine properties, but that
probably will get quite a push back so unless I find compelling reason
to do it I won't care much as '-m' would be a lightweight shim over
machine properties.
>
> Paolo
>
