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: Thu, 21 Mar 2019 19:27:50 +0300

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




reply via email to

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