Re: [PATCH V3 01/16] machine: anon-alloc option

[Peter Xu]

On Fri, Nov 08, 2024 at 09:14:02AM -0500, Steven Sistare wrote:
> > Could anyone remind me why we can't simply set PRIVATE|SHARED all over the
> > place?
> > 
> > IMHO RAM_AUX is too hard for any new callers to know how to set.  It's much
> > easier when we already have SHARED, adding PRIVATE could be mostly natural,
> > then we can already avoid AUX due to checking !SHARED & !PRIVATE.
> > 
> > Basically, SHARED|PRIVATE then must come from an user request (QMP or
> > cmdline), otherwise the caller should always set none of them, implying
> > aux.
> > 
> > It still looks the best to me.
> 
> Our emails crossed. We could set PRIVATE|SHARED all over the place.  Nothing
> wrong with that solution. I have no preference, other than finishing.

The current AUX is exactly what I was picturing when I was replying v2, so
the four paths you listed here:

44b15731-0ee8-4e24-b4f5-0614bca594cb@oracle.com/">https://lore.kernel.org/qemu-devel/44b15731-0ee8-4e24-b4f5-0614bca594cb@oracle.com/

        Agreed, RAM_AUX is a clear solution.  I would set it in these
        functions:

                qemu_ram_alloc_resizeable
                memory_region_init_ram_nomigrate
                memory_region_init_rom_nomigrate
                memory_region_init_rom_device_nomigrate


That is what I listed previously:

https://lore.kernel.org/qemu-devel/Zv7C7MeVP2X8bEJU@x1n/

        I think that means below paths [1-4] are only relevant:

        qemu_ram_alloc
                memory_region_init_rom_device_nomigrate [1]
                memory_region_init_ram_flags_nomigrate
                        memory_region_init_ram_nomigrate    [2]
                        memory_region_init_rom_nomigrate    [3]
        qemu_ram_alloc_resizeable                   [4]

Except that if we don't want to risk using VM_SHARED unconditionally on
linux for aux, then we need to have a new flag, aka RAM_AUX or similar.

So I believe the list is at least correct.

I changed my mind because I noticed it will be non-trivial to know whether
one should set RAM_AUX when a new user needs to create some new ramblocks.

In that case, we need to define RAM_AUX properly.  One sane way to define
it is: "if the user didn't specify share or private property, please use
AUX", but then it'll overlap with RAM_SHARED / RAM_PRIVATE already, hence
redundant.

Yes, let's wait and see David's comment.

Thanks,

-- 
Peter Xu