11.01.2019, 23:55, "Eduardo Habkost" <ehabk...@redhat.com>: > On Fri, Jan 11, 2019 at 06:49:53PM +0300, Yury Kotov wrote: >> 10.01.2019, 23:12, "Dr. David Alan Gilbert" <dgilb...@redhat.com>: >> > * Yury Kotov (yury-ko...@yandex-team.ru) wrote: >> >> Hi, >> >> >> >> The series adds migration capability which allows to skip 'external' RAM >> blocks >> >> during migration. External block is a RAMBlock which available from the >> outside >> >> of current QEMU process (e.g. file in /dev/shm). It's useful for fast >> local >> >> migration to update QEMU for the running guests. >> > >> > Hi Yury, >> > There have been a few similar patch series around from people wanting >> > to do similar things. >> > In particular Lai Jiangshan's >> https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg07511.html >> > and Cédric Le Goater wanted to skip regions for a different reason. >> > >> > We merged some of Cédric's code last year so that we now >> > have the qemu_ram_is_migratable() function - and we should be reusing >> > that to skip things rather than adding a new check that we have to add >> > everywhere. >> > >> >> I didn't see the series, so I'll check it, thanks! >> But I saw qemu_ram_is_migratable() function and corresponding patch. >> It's very close to my needs, but it works a bit different IIUC: >> 1. Not migratable blocks isn't validated (existence and size) during >> migration, >> 2. "Migratable" state is determined during the block creation time. >> Such case isn't valid because of it: >> * Source has one migratable and one not migratable RAM blocks, >> * Target has the same (idstr) blocks, but both are not migratable. >> Thus, target will not expect pages for not migratable blocks. >> >> > Also, ypu're skipping 'external' things, I think the other suggestion >> > was to skip 'shared' things (i.e. anything with share=0); skipping >> > share=on cases sounds easier to me. >> >> I agree that introducing new term is a complication, but 'share' and >> 'external' >> terms have important differences (I'll describe it below). >> >> Just to clarify: >> * 'share' means that other processes has an access to such memory, >> * 'external' means file backed memory. > > If you use file backed memory with share=off, writes are not > propagated to the file (they are mapped with MAP_PRIVATE). Would > you really want to skip file backed memory if it has share=off? >
Yes, you're right. I was sure it would work, but share=on is also needed in my case. >> There is another use case I wanted to support (I had to write about it in >> the cover letter, sorry..): >> 1. Migrate source VM to file and kill source, >> 2. Start target VM and migrate it from file. >> In such case source VM may have memory-backend-ram with share=off, it's ok. >> >> Thus, in the new migration capability I want to migrate memory that meets >> three conditions: >> 1. The source will not use the memory after migration ends, >> 2. The source may exit before target starts (migrate to file), >> 3. The target has an access to the memory. >> >> I think 'external' fits them better than 'share'. > > In either case, defining "external" seems tricky. A memory > region might be backed by a file on tmpfs or hugetlbfs that was > deleted, which makes the file "internal" for practical purposes. > QEMU has no way to tell if (3) is really true. > > -- > Eduardo Agree. Perhaps the best is a separate flag, as suggested by Dave. Regards, Yury
