Re: [PATCH REPOST v3 78/80] hostmem: fix strict bind policy

[Igor Mammedov]

On Mon, 27 Jan 2020 15:41:45 +0100
Halil Pasic <address@hidden> wrote:

> On Mon, 27 Jan 2020 08:39:25 +0100
> Igor Mammedov <address@hidden> wrote:
> 
> > On Fri, 24 Jan 2020 20:17:48 +0100
> > Halil Pasic <address@hidden> wrote:
> >   
> > > On Thu, 23 Jan 2020 12:38:43 +0100
> > > Igor Mammedov <address@hidden> 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
>