qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resiz


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 15:19:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0


On 19/11/2014 15:10, Peter Maydell wrote:
> On 19 November 2014 14:07, Juan Quintela <address@hidden> wrote:
> > My understanding is that it is a "trick".  We have internal memory for a
> > device that is needed for the emulation, but not showed to the guest.
> > And it is big enough that we want to save it during the "live" stage of
> > migration, so we mark it as RAM.  if it is somekind of cash, we can just
> > enlarge it on destination, and it don't matter.  If this has anything
> > different on the other part of the RAM, we are on trouble.
>
> Would it be feasible to just have the migration code provide
> an API for registering things to be migrated in the live
> migration stage, rather than creating memory regions which
> you can't actually use for most of the purposes the memory
> region API exists for?

It does already, for example PPC uses it for its IOMMU tables.

But in any case this is really just memory that is auto-resized on
migration.  And it can work even if it is mapped in memory, as long as
your resize callback (or some post_load code executed while migrating
devices) does something useful to update the memory map.  Let's call it
like what it is.

Basically it is an "I know how to deal with the source's configuration
whatever it is, so I'm not bothering to reconstruct it equivalently on
the destination" flag.

The fine print is that it will create more differences between a given
machine type on different versions of QEMU.  It can have ripple effects
on the memory map and it can make existing VMs a bit more likely to
break when updating QEMU.  This is why I do not particularly like it,
and I posted different patches to do the same thing.  I understand that
it is a simple fix that will mostly work and probably avoids work more
than causing it.

And BTW, those patches are still unreviewed,.  Juan, "do as you
preach"---review patches that are closer to what you preach.  And
Michael, you too---review patches in addition to asking people to review
yours, so that we can compare the approaches.

Paolo



reply via email to

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