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

[David Hildenbrand <david@redhat.com>]

On 08.11.24 16:07, Peter Xu wrote:
> 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..

Likely not. When the code was introduced we used magic boolean 
parameters and likely "true" was set by accident.

There are not that many RAM_SHARED users at all ...

Anyhow ....

  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.

I think I still prefer RAM_NO_AUX, but I'll leave it to you and Steven 
to figure out, it's been way to many emails at this point :)

-- 
Cheers,

David / dhildenb