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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 16:08:30 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Nov 19, 2014 at 03:18:01PM +0100, Juan Quintela wrote:
> Peter Maydell <address@hidden> 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?
> 
> If somebody told me what they need, we can do it.
> 
> Stefan, you needed something like that for data-plane?  Or that memory
> is mapped on the guest?

No, dataplane has no special requirements here.

I am working on making the dirty memory bitmap atomic so that dataplane
threads can dirty memory at the same time as other threads.  But that's
a different topic from what you are discussing here.

Stefan

Attachment: pgplMEGYS4vZk.pgp
Description: PGP signature


reply via email to

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