On Mon, 27 Jan 2020 15:41:45 +0100 Halil Pasic <pa...@linux.ibm.com> wrote:
> On Mon, 27 Jan 2020 08:39:25 +0100 > Igor Mammedov <imamm...@redhat.com> wrote: > > > On Fri, 24 Jan 2020 20:17:48 +0100 > > Halil Pasic <pa...@linux.ibm.com> wrote: > > > > > On Thu, 23 Jan 2020 12:38:43 +0100 > > > Igor Mammedov <imamm...@redhat.com> wrote: > > > > > > > With main RAM now converted to hostmem backends, there is no > > > > point in keeping global mem_prealloc around, so alias > > > > -mem-prealloc to "memory-backend.prealloc=on" > > > > machine compat[*] property and make mem_prealloc a local > > > > variable to only stir registration of compat property. > > > > > > > > *) currently user accessible -global works only with DEVICE > > > > based objects and extra work is needed to make it work > > > > with hostmem backends. But that is convenience option > > > > and out of scope of this already huge refactoring. > > > > Hence machine compat properties were used. > > > > > > AFAIU because of this something like > > > -global memory-backend-file.share=on > > > (as proposed by > > > https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00531.html) > > > can not be used to make the main RAM shared (e.g. for vhost on s390x). > > > Or am I wrong? If not, is -global still the way we want to make this work > > > for non-numa machines, or did I miss updates? > > > > one should be able to use memory-backend property to make it work > > instead of -m convenience option in s390 case. > > Thank you very much for the quick response! > > Honestly, I overlooked the memory-backed machine property, but regardless > of that -machine,memory-backend=id *does not seem viable* at the > moment. > > My understanding is that one has to do something like: > -machine type=s390-ccw-virtio,memory-backend=mem \ > -object > memory-backend-file,id=mem,size=2G,mem-path=/dev/shm/virtiofs.shm,share=on \ > > I get > qemu: : Device 'mem' not found > because the 'memory-backend-*' objects are delayed, > i.e. !object_create_initial(), and at the time when > machine_set_property() tries to look the memory-backend up the > memory-backend is not yet created. > > For why delayed, object_create_initial() has a comment: > > /* Memory allocation by backends needs to be done > * after configure_accelerator() (due to the tcg_enabled() > * checks at memory_region_init_*()). > * > * Also, allocation of large amounts of memory may delay > * chardev initialization for too long, and trigger timeouts > * on software that waits for a monitor socket to be created > * (e.g. libvirt). > */ > if (g_str_has_prefix(type, "memory-backend-")) { > > Or, am I using it wrong? You right, I even had an alternative impl. earlier that used string property instead of link, but later I forgot about this complication and simplified it to link property which works fine but only for -m case. It's necessary to rewrite patches 2-4/80 to use string property for memory-backend which will be used for delayed backend access at machine_run_board_init() time. I'll CC you on relevant patches for reviewing when I post v4. > > > > As for -global for objects (or more limited variant for memory-backends), > > it needs more work to support objects. (that's mostly policy decision) > > > > I agree. > > Regards, > Halil >
