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

[Peter Xu <peterx@redhat.com>]

On Fri, Nov 08, 2024 at 03:54:13PM +0100, David Hildenbrand wrote:
> Likely AUX is everything that is "neither explicitly specified by the user nor
> very special RAM"
> 
> So I think hw/misc/ivshmem.c would also not count as "aux", and similarly
> hw/remote/memory.c; both use memory_region_init_ram_from_fd(share=on).
> 
> memory_region_init_ram_ptr/memory_region_init_ram_device_ptr are similarly
> special: we cannot possibly turn them SHARED. But that's also what your code
> already handled.
> 
> So maybe, really everything is AUX ram, except
> * Using memory_region_init_ram_from_fd()/
>   memory_region_init_ram_from_file() users.
> * Using memory_region_init_ram_ptr / memory_region_init_ram_device_ptr
> * Created via memory backends
> 
> 
> Note that hw/m68k/next-cube.c is one odd RAM_SHARED user. I don't know why
> it uses RAM_SHARED to get anonymous shared RAM. Likely a mistake when that
> code was introduced.
> 
> CCing Thomas.
> 
> commit 956a78118bfc7fa512b03cbe8a77b9384c6d89f4
> Author: Thomas Huth <huth@tuxfamily.org>
> Date:   Sat Jun 30 08:45:25 2018 +0200
> 
>     m68k: Add NeXTcube machine
>     It is still quite incomplete (no SCSI, no floppy emulation, no network,
>     etc.), but the firmware already shows up the debug monitor prompt in the
>     framebuffer display, so at least the very basics are already working.
>     This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>      https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-cube.c
>     and altered quite a bit to fit the latest interface and coding conventions
>     of the current QEMU.

This might also imply that our current RAM_SHARED is already not crystal
clear on when to use, not to mention RAM_AUX if to be introduced..  Please
see my other email, trying to define RAM_SHARED properly.

IIUC after we can properly define RAM_SHARED, then we don't need AUX, and
everything will be crystal clear.

Thanks,

-- 
Peter Xu