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

[Yury Kotov]

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