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

[Peter Xu <peterx@redhat.com>]

On Mon, Nov 04, 2024 at 08:51:56PM +0100, David Hildenbrand wrote:
> > I did that previously, and Peter objected, saying the explicit anon-shared
> > should not override the implicit shared=off.
> 
> Yes, it's better if we can detect that somehow. There should be easy ways to
> make that work, so I wouldn't worry about that.

I still think whenever the caller is capable of passing RAM_SHARED flag
into ram_block_add(), we should always respect what's passed in from the
caller, no matter it's a shared / private request.

A major issue with that idea is when !RAM_SHARED, we don't easily know
whether it's because the caller explicitly chose share=off, or if it's
simply the type of ramblock that we don't care (e.g. ROMs).

So besides what I used to suggest on monitoring the four call sites that
can involve those, another simpler (and now I see it even cleaner..) way
could be that we explicitly introduce RAM_PRIVATE.  It means whenever we
have things like below in the callers:

    int ram_flags = shared ? RAM_SHARED : 0;

We start to switch to:

    int ram_flags = shared ? RAM_SHARED : RAM_PRIVATE;

Then in ram_block_add():

    if (!(ram_flags & (RAM_SHARED | RAM_PRIVATE))) {
        // these are the target ramblocks for cpr's whatever new machine
        // flag..
    }

-- 
Peter Xu