On Fri, Nov 08, 2024 at 03:18:07PM +0100, David Hildenbrand 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. > > How is it clearer if you have to know whether you have to set RAM_PRIVATE or > not for some RAM? Because you *wouldn't* set it "all over the place".
I think I answered that in previous reply, but exactly after the line where it got cut-off.. :) https://lore.kernel.org/qemu-devel/Zy4VkScMEpYayGtM@x1n/ Basically, SHARED|PRIVATE then must come from an user request (QMP or cmdline), otherwise the caller should always set none of them, implying aux. But I confess that's not accurate.. some caller is based on type of objects etc. to decide mem must be SHARED. A better version could be: RAM_SHARED|RAM_PRIVATE describes the share-able attribute of the RAM block. It can never be set together. When one is set, the memory attribute must suffice the request. When none is set, QEMU will decide how to request the memory. The flag should only be set if the caller has explicit requirement on such memory property. For example, it can come from either a request from user (share=on/off), or the memory must be shared / private due to its own attribute (shm objects, like ivshmem, shm backend, or remotely shared mem, etc.). Otherwise, callers should leave both flags unset. Maybe we should document this directly into the flag definitions, so what flags to set would be clearer than before, and just to say it's not the caller's own willingness to set SHARED | PRIVATE randomly (so as to make cpr available as much as possible). Thanks, -- Peter Xu
