Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Юрий Котов]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Dr. David Alan Gilbert]

* Юрий Котов (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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Yury Kotov]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Yury Kotov]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Yury Kotov]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Yury Kotov]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Eduardo Habkost]

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

Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts

[Yury Kotov]

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