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
