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" <address@hidden>:
> 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" <address@hidden>:
>>  > Ping
>>  >
>>  > 04.04.2019, 13:01, "Yury Kotov" <address@hidden>:
>>  >>  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" <address@hidden>:
>>  >>>   * Юрий Котов (address@hidden) wrote:
>>  >>>>    Ping
>>  >>>
>>  >>>   Is this fixed by Catherine Ho's patch series?
>>  >>>
>>  >>>   Dave
>>  >>>
>>  >>>>    21.03.2019, 19:27, "Yury Kotov" <address@hidden>:
>>  >>>>    > Hi,
>>  >>>>    >
>>  >>>>    > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <address@hidden>:
>>  >>>>    >>  * Peter Maydell (address@hidden) wrote:
>>  >>>>    >>>   On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
>>  >>>>    >>>   <address@hidden> wrote:
>>  >>>>    >>>   >
>>  >>>>    >>>   > * Peter Maydell (address@hidden) 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 / address@hidden / Manchester, UK
>>  >>>>    >
>>  >>>>    > Regards,
>>  >>>>    > Yury
>>  >>>   --
>>  >>>   Dr. David Alan Gilbert / address@hidden / Manchester, UK
>
> --
> Eduardo

Regards,
Yury