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. > > 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..). CPR has a pretty tricky way of using VFIO pgtables in that it requires the PFNs to not change before/after migration. Feel free to have a look at VFIO_DMA_MAP_FLAG_VADDR in vfio.h then you may get a feeling of it. Thanks, -- Peter Xu
