qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Yury Kotov
Subject: Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
Date: Tue, 14 May 2019 12:42:14 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]