* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 19 Mar 2019 at 09:40, Dr. David Alan Gilbert > <dgilb...@redhat.com> 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 / dgilb...@redhat.com / Manchester, UK
