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

[Igor Mammedov]

On Tue, 19 Mar 2019 11:52:45 +0000
"Dr. David Alan Gilbert" <address@hidden> wrote:

> * 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.
on aarch(64) we also load dtb into main RAM currently only on boot,
and I was planning to move it to reset stage to accommodate
hotplug usecase so that guest would pick up hotplugged
devices after reboot.
If guest clobbers dtb area for any reason, then shared memory
usecase is currently broken since destination QEMU will
overwrite it on initial startup.


> Dave
> 
> > thanks
> > -- PMM  
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK