Re: [Qemu-devel] [PATCH v4 2/2] loader: store FW CFG ROM files in RAM

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 19, 2013 at 07:28:12PM +0200, Paolo Bonzini wrote:
> Il 19/08/2013 16:26, Michael S. Tsirkin ha scritto:
> > ROM files that are put in FW CFG are copied to guest ram, by BIOS, but
> > they are not backed by RAM so they don't get migrated.
> > 
> > Each time we change two bytes in such a ROM this breaks cross-version
> > migration: since we can migrate after BIOS has read the first byte but
> > before it has read the second one, getting an inconsistent state.
> > 
> > Future-proof this by creating, for each such ROM,
> > an MR serving as the backing store.
> > This MR is never mapped into guest memory, but it's registered
> > as RAM so it's migrated with the guest.
> > 
> > Naturally, this only helps for -M 1.7 and up, older machine types
> > will still have the cross-version migration bug.
> > Luckily the race window for the problem to trigger is very small,
> > which is also likely why we didn't notice the cross-version
> > migration bug in testing yet.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> This doesn't really help much unless we support migration of
> different-sized RAM regions, does it?

It does because RAM blocks are multiples of target pages, so the size
won't change all that much. This is more or less similar to what happens
e.g. with BIOS (aligned to power of two).
It worked for BIOS for a while.


> In particular, what happens if
> the region is smaller on the destination?  Do we get garbage written out
> of a malloc-ed region's bounds?

No, migration fails if block size does not match.

> The patches look good, but I'm not sure they are an improvement yet.
> 
> Paolo

Well they protect us against minor changes which are
IMO more likely than major changes.

We can add code to allow ram block size changes on top.
I'm not sure it's a requirement right now.

-- 
MST