* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
@ 2019-04-03 9:29 Юрий Котов
2019-04-04 9:52 ` Dr. David Alan Gilbert
0 siblings, 1 reply; 8+ messages in thread
From: Юрий Котов @ 2019-04-03 9:29 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Peter Maydell
Cc: Eduardo Habkost, Juan Quintela, Markus Armbruster,
QEMU Developers, Paolo Bonzini, Igor Mammedov, wrfsh,
Richard Henderson
Ping
21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
> Hi,
>
> 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>>> <dgilbert@redhat.com> wrote:
>>> >
>>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>
> Regards,
> Yury
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
2019-04-03 9:29 [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts Юрий Котов
@ 2019-04-04 9:52 ` Dr. David Alan Gilbert
2019-04-04 10:01 ` Yury Kotov
0 siblings, 1 reply; 8+ messages in thread
From: Dr. David Alan Gilbert @ 2019-04-04 9:52 UTC (permalink / raw)
To: Юрий Котов
Cc: Peter Maydell, Eduardo Habkost, Juan Quintela, Markus Armbruster,
QEMU Developers, Paolo Bonzini, Igor Mammedov, wrfsh,
Richard Henderson
* Юрий Котов (yury-kotov@yandex-team.ru) wrote:
> Ping
Is this fixed by Catherine Ho's patch series?
Dave
> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
> > Hi,
> >
> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
> >>> <dgilbert@redhat.com> wrote:
> >>> >
> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
> >
> > Regards,
> > Yury
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
2019-04-04 9:52 ` Dr. David Alan Gilbert
@ 2019-04-04 10:01 ` Yury Kotov
2019-04-17 12:46 ` Yury Kotov
0 siblings, 1 reply; 8+ messages in thread
From: Yury Kotov @ 2019-04-04 10:01 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Peter Maydell, Eduardo Habkost, Juan Quintela, Markus Armbruster,
QEMU Developers, Paolo Bonzini, Igor Mammedov, wrfsh,
Richard Henderson
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" <dgilbert@redhat.com>:
> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
>> Ping
>
> Is this fixed by Catherine Ho's patch series?
>
> Dave
>
>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
>> > Hi,
>> >
>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>> >>> <dgilbert@redhat.com> wrote:
>> >>> >
>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>> >
>> > Regards,
>> > Yury
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
@ 2019-04-17 12:46 ` Yury Kotov
0 siblings, 0 replies; 8+ messages in thread
From: Yury Kotov @ 2019-04-17 12:46 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Peter Maydell, Eduardo Habkost, Juan Quintela, Markus Armbruster,
QEMU Developers, Paolo Bonzini, Igor Mammedov, wrfsh,
Richard Henderson
Ping
04.04.2019, 13:01, "Yury Kotov" <yury-kotov@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" <dgilbert@redhat.com>:
>> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
>>> Ping
>>
>> Is this fixed by Catherine Ho's patch series?
>>
>> Dave
>>
>>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
>>> > Hi,
>>> >
>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>>> >>> <dgilbert@redhat.com> wrote:
>>> >>> >
>>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>>> >
>>> > Regards,
>>> > Yury
>> --
>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
@ 2019-04-17 12:46 ` Yury Kotov
0 siblings, 0 replies; 8+ messages in thread
From: Yury Kotov @ 2019-04-17 12:46 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Peter Maydell, Eduardo Habkost, Juan Quintela, QEMU Developers,
Markus Armbruster, Igor Mammedov, Paolo Bonzini, wrfsh,
Richard Henderson
Ping
04.04.2019, 13:01, "Yury Kotov" <yury-kotov@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" <dgilbert@redhat.com>:
>> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
>>> Ping
>>
>> Is this fixed by Catherine Ho's patch series?
>>
>> Dave
>>
>>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
>>> > Hi,
>>> >
>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>>> >>> <dgilbert@redhat.com> wrote:
>>> >>> >
>>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>>> >
>>> > Regards,
>>> > Yury
>> --
>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
2019-04-17 12:46 ` Yury Kotov
(?)
@ 2019-05-14 9:42 ` Yury Kotov
2019-05-17 18:25 ` Eduardo Habkost
-1 siblings, 1 reply; 8+ messages in thread
From: Yury Kotov @ 2019-05-14 9:42 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Peter Maydell, Eduardo Habkost, Juan Quintela, QEMU Developers,
Markus Armbruster, Igor Mammedov, Paolo Bonzini, wrfsh,
Richard Henderson
Ping ping
17.04.2019, 15:46, "Yury Kotov" <yury-kotov@yandex-team.ru>:
> Ping
>
> 04.04.2019, 13:01, "Yury Kotov" <yury-kotov@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" <dgilbert@redhat.com>:
>>> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
>>>> Ping
>>>
>>> Is this fixed by Catherine Ho's patch series?
>>>
>>> Dave
>>>
>>>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
>>>> > Hi,
>>>> >
>>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>>>> >>> <dgilbert@redhat.com> wrote:
>>>> >>> >
>>>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>>>> >
>>>> > Regards,
>>>> > Yury
>>> --
>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
2019-05-14 9:42 ` Yury Kotov
@ 2019-05-17 18:25 ` Eduardo Habkost
2019-05-20 7:50 ` Yury Kotov
0 siblings, 1 reply; 8+ messages in thread
From: Eduardo Habkost @ 2019-05-17 18:25 UTC (permalink / raw)
To: Yury Kotov
Cc: Peter Maydell, Juan Quintela, Markus Armbruster, QEMU Developers,
Dr. David Alan Gilbert, Igor Mammedov, Paolo Bonzini, wrfsh,
Richard Henderson
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-kotov@yandex-team.ru>:
> > Ping
> >
> > 04.04.2019, 13:01, "Yury Kotov" <yury-kotov@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" <dgilbert@redhat.com>:
> >>> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
> >>>> Ping
> >>>
> >>> Is this fixed by Catherine Ho's patch series?
> >>>
> >>> Dave
> >>>
> >>>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
> >>>> > Hi,
> >>>> >
> >>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
> >>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
> >>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
> >>>> >>> <dgilbert@redhat.com> wrote:
> >>>> >>> >
> >>>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
> >>>> >
> >>>> > Regards,
> >>>> > Yury
> >>> --
> >>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
--
Eduardo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
2019-05-17 18:25 ` Eduardo Habkost
@ 2019-05-20 7:50 ` Yury Kotov
0 siblings, 0 replies; 8+ messages in thread
From: Yury Kotov @ 2019-05-20 7:50 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Peter Maydell, Juan Quintela, Markus Armbruster, QEMU Developers,
Dr. David Alan Gilbert, Igor Mammedov, Paolo Bonzini, wrfsh,
Richard Henderson
It's to detect those cases in the future, yes.
17.05.2019, 21:25, "Eduardo Habkost" <ehabkost@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-kotov@yandex-team.ru>:
>> > Ping
>> >
>> > 04.04.2019, 13:01, "Yury Kotov" <yury-kotov@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" <dgilbert@redhat.com>:
>> >>> * Юрий Котов (yury-kotov@yandex-team.ru) wrote:
>> >>>> Ping
>> >>>
>> >>> Is this fixed by Catherine Ho's patch series?
>> >>>
>> >>> Dave
>> >>>
>> >>>> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
>> >>>> > Hi,
>> >>>> >
>> >>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
>> >>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> >>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>> >>>> >>> <dgilbert@redhat.com> wrote:
>> >>>> >>> >
>> >>>> >>> > * Peter Maydell (peter.maydell@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 / dgilbert@redhat.com / Manchester, UK
>> >>>> >
>> >>>> > Regards,
>> >>>> > Yury
>> >>> --
>> >>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
> --
> Eduardo
Regards,
Yury
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-05-20 7:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-03 9:29 [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts Юрий Котов
2019-04-04 9:52 ` Dr. David Alan Gilbert
2019-04-04 10:01 ` Yury Kotov
2019-04-17 12:46 ` Yury Kotov
2019-04-17 12:46 ` Yury Kotov
2019-05-14 9:42 ` Yury Kotov
2019-05-17 18:25 ` Eduardo Habkost
2019-05-20 7:50 ` Yury Kotov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.