On Fri, 15 Jan 2021 10:36:05 +0100 Michal Privoznik <mpriv...@redhat.com> wrote:
> On 1/15/21 12:46 AM, Igor Mammedov wrote: > > Add documentation for '-machine memory-backend' CLI option and > > how to use it. > > > > And document that x-use-canonical-path-for-ramblock-id, > > is considered to be stable to make sure it won't go away by accident. > > > > Signed-off-by: Igor Mammedov <imamm...@redhat.com> > > --- > > v2: > > - add doc that x-use-canonical-path-for-ramblock-id is considered stable, > > (Peter Krempa <pkre...@redhat.com>) > > --- > > backends/hostmem.c | 10 ++++++++++ > > qemu-options.hx | 28 +++++++++++++++++++++++++++- > > 2 files changed, 37 insertions(+), 1 deletion(-) > > > > > > @@ -96,6 +97,31 @@ SRST > > ``hmat=on|off`` > > Enables or disables ACPI Heterogeneous Memory Attribute Table > > (HMAT) support. The default is off. > > + > > + ``memory-backend='id'`` > > + An alternative to legacy ``-mem-path`` and ``mem-prealloc`` > > options. > > + Allows to use a memory backend as main RAM. > > + > > + For example: > > + :: > > + -object > > memory-backend-file,id=pc.ram,size=512M,mem-path=/hugetlbfs,prealloc=on,share=on > > + -machine memory-backend=pc.ram > > + -m 512M > > + > > + Migration compatibility note: > > + a) as backend id one shall use value of 'default-ram-id', > > advertised by > > + machine type (available via ``query-machines`` QMP command) > > + b) for machine types 4.0 and older, user shall > > + use ``x-use-canonical-path-for-ramblock-id=on`` backend option > > + (this option must be considered stable, as if it didn't have the > > 'x-' > > + prefix including deprecation period, as long as 4.0 and older > > machine > > + types exists), > > + if migration to/from old QEMU (<5.0) is expected. > > + For example: > > + :: > > + -object > > memory-backend-ram,id=pc.ram,size=512M,x-use-canonical-path-for-ramblock-id=on > > + -machine memory-backend=pc.ram > > + -m 512M > > Igor, this doesn't correspond with your comment in bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1836043#c31 > > In fact, we had to turn the attribute OFF so that canonical path is not > used. Isn't ON the default state anyway? indeed, it should be 'off', > > Michal > >
