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

[Dr. David Alan Gilbert]

* Peter Maydell (address@hidden) wrote:
> On Tue, 19 Mar 2019 at 09:40, Dr. David Alan Gilbert
> <address@hidden> wrote:
> > I thought that ROMs would either:
> >    a) Be mapped shared from a file but then read-only and unwritten
> 
> I don't think we support this at all, do we?

OK, I thought we did somewhere but I might be dreaming it.

> > or
> >    b) Be written to during boot - but this wouldn't be main memory, so
> > wouldn't be affected by your shared flag.
> 
> The rom code in hw/core/loader.c has two basic cases:
>  (1) file is being loaded to something that is really a pure ROM:
> in this case, on first reset we will write it to the backing RAMBlock
> but we will not bother to do so in future
>  (2) file is being loaded to something that is not a pure ROM:
> this could be either real RAM (eg if a file is loaded via -kernel
> or the 'generic loader' device), or a flash device, for instance.
> In this case we will reload the backing RAMBlock with the file
> contents on every reset, because the guest might have changed its
> contents.
> (There's also "file is provided via the fw_cfg device" but that's
> not relevant here.)
> 
> 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.

Dave



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