It's to detect those cases in the future, yes. 17.05.2019, 21:25, "Eduardo Habkost" <ehabk...@redhat.com>: > My memory is failing here: do we still need to fix a bug where > there are unexpected writes to system_memory, or this is just a > request to include a mechanism to help us detect those cases in > the future? > > On Tue, May 14, 2019 at 12:42:14PM +0300, Yury Kotov wrote: >> Ping ping >> >> 17.04.2019, 15:46, "Yury Kotov" <yury-ko...@yandex-team.ru>: >> > Ping >> > >> > 04.04.2019, 13:01, "Yury Kotov" <yury-ko...@yandex-team.ru>: >> >> I saw Catherine Ho's patch series and it seems ok to me, but in this >> RFC I asked >> >> about a way how to detect other writes which may not be covered by >> particular >> >> fixes. >> >> Perhaps this is excessive caution... >> >> >> >> Regards, >> >> Yury >> >> >> >> 04.04.2019, 12:52, "Dr. David Alan Gilbert" <dgilb...@redhat.com>: >> >>> * Юрий Котов (yury-ko...@yandex-team.ru) wrote: >> >>>> Ping >> >>> >> >>> Is this fixed by Catherine Ho's patch series? >> >>> >> >>> Dave >> >>> >> >>>> 21.03.2019, 19:27, "Yury Kotov" <yury-ko...@yandex-team.ru>: >> >>>> > Hi, >> >>>> > >> >>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilb...@redhat.com>: >> >>>> >> * Peter Maydell (peter.mayd...@linaro.org) wrote: >> >>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert >> >>>> >>> <dgilb...@redhat.com> wrote: >> >>>> >>> > >> >>>> >>> > * Peter Maydell (peter.mayd...@linaro.org) wrote: >> >>>> >>> > > I didn't think migration distinguished between "main >> memory" >> >>>> >>> > > and any other kind of RAMBlock-backed memory ? >> >>>> >>> > >> >>>> >>> > In Yury's case there's a distinction between RAMBlock's >> that are mapped >> >>>> >>> > with RAM_SHARED (which normally ends up as MAP_SHARED) and >> all others. >> >>>> >>> > You can set that for main memory by using -numa to specify >> a memdev >> >>>> >>> > that's backed by a file and has the share=on property. >> >>>> >>> > >> >>>> >>> > On x86 the ROMs end up as separate RAMBlock's that aren't >> affected >> >>>> >>> > by that -numa/share=on - so they don't fight Yury's trick. >> >>>> >>> >> >>>> >>> You can use the generic loader on x86 to load an ELF file >> >>>> >>> into RAM if you want, which would I think also trigger this. >> >>>> >> >> >>>> >> OK, although that doesn't worry me too much - since in the >> majority >> >>>> >> of cases Yury's trick still works well. >> >>>> >> >> >>>> >> I wonder if there's a way to make Yury's code to detect these >> cases >> >>>> >> and not allow the feature; the best thing for the moment would >> seem to >> >>>> >> be to skip the aarch test that uses elf loading. >> >>>> > >> >>>> > Currently, I've no idea how to detect such cases, but there is an >> ability to >> >>>> > detect memory corruption. I want to update the RFC patch to let >> user to map some >> >>>> > memory regions as readonly until incoming migration start. >> >>>> > >> >>>> > E.g. >> >>>> > 1) If x-ignore-shared is enabled in command line or memory region >> is marked >> >>>> > (something like ',readonly=on'), >> >>>> > 2) Memory region is shared (,share=on), >> >>>> > 3) And qemu is started with '-incoming' option >> >>>> > >> >>>> > Then map such regions as readonly until incoming migration >> finished. >> >>>> > Thus, the patch will be able to detect memory corruption and will >> not affect >> >>>> > normal cases. >> >>>> > >> >>>> > How do you think, is it needed? >> >>>> > >> >>>> > I already have a cleaner version of the RFC patch, but I'm not >> sure about 1). >> >>>> > Which way is better: enable capability in command line, add a new >> option for >> >>>> > memory-backend or something else. >> >>>> > >> >>>> >> Dave >> >>>> >> >> >>>> >>> thanks >> >>>> >>> -- PMM >> >>>> >> -- >> >>>> >> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >> >>>> > >> >>>> > Regards, >> >>>> > Yury >> >>> -- >> >>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > -- > Eduardo
Regards, Yury
