On 04.06.24 18:41, Peter Xu wrote:
On Tue, Jun 04, 2024 at 06:14:08PM +0200, David Hildenbrand wrote:
On 04.06.24 17:58, Peter Xu wrote:
On Tue, Jun 04, 2024 at 08:13:26AM +0100, Daniel P. Berrangé wrote:
On Mon, Jun 03, 2024 at 05:48:32PM -0400, Peter Xu wrote:
That property, irrelevant of what it is called (and I doubt whether Dan's
suggestion on "shared-ram" is good, e.g. mmap(MAP_SHARED) doesn't have user
visible fd but it's shared-ram for sure..), is yet another way to specify
guest mem types.
What if the user specified this property but specified something else in
the -object parameters? E.g. -machine share-ram=on -object
memory-backend-ram,share=off. What should we do?
The machine property would only apply to memory regions that are
*NOT* being created via -object. The memory-backend objects would
always honour their own share settnig.
In that case we may want to rename that to share-ram-by-default=on.
Otherwise it's not clear which one would take effect from an user POV, even
if we can define it like that in the code.
Even with share-ram-by-default=on, it can be still confusing in some form
or another. Consider this cmdline:
-machine q35,share-ram-by-default=on -object memory-backend-ram,id=mem1
Then is mem1 shared or not? From reading the cmdline, if share ram by
default it should be ON if we don't specify it, but it's actually off?
It's because -object has its own default values.
We do have something similar with "merge" and "dump" properties. See
machine_mem_merge() / machine_dump_guest_core().
These correspond to the "mem-merge" and "dump-guest-core" machine
properties.
These look fine so far, as long as -object cmdline doesn't allow to specify
the same thing again.
You can. The mem-merge / dump-guest-core set the default that can be
modified per memory backend (merge / dump properties).
But ...
IMHO fundamentally it's just controversial to have two ways to configure
guest memory. If '-object' is the preferred and complete way to configure
it, I prefer sticking with it if possible and see what is missing.
... I agree with that. With vhost-user we also require a reasonable
configuration (using proper fd-based shared memory) for it to work.
I think I raised that as the other major reason too, that I think it's so
far only about the vram that is out of the picture here. We don't and
shouldn't have complicated RW RAMs floating around that we want this
property to cover.
Agreed. And maybe we can still keep migration of any MAP_PRIVATE thing
working by migrating that memory? CPR will be "slightly less fast".
But the biggest piece -- guest RAM -- will be migrated via the fd directly.
I think it should work but only without VFIO. When with VFIO there must
have no private pages at all or migrating is racy with concurrent DMAs
(yes, AFAICT CPR can run migration with DMA running..).
Understood. For these we could fail migration. Thanks for the pointer.
--
Cheers,
David / dhildenb
