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?
Michal
