qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] migration: discard non-migratable RAMBlocks


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [PATCH v2] migration: discard non-migratable RAMBlocks
Date: Fri, 20 Apr 2018 11:24:28 +0200
User-agent: NeoMutt/20170609 (1.8.3)

On Fri, Apr 20, 2018 at 10:14:15AM +0200, KONRAD Frederic wrote:
> 
> 
> On 04/19/2018 07:45 PM, Edgar E. Iglesias wrote:
> > On Thu, Apr 19, 2018 at 06:32:07PM +0100, Peter Maydell wrote:
> > > On 13 April 2018 at 08:52, Cédric Le Goater <address@hidden> wrote:
> > > > On the POWER9 processor, the XIVE interrupt controller can control
> > > > interrupt sources using MMIO to trigger events, to EOI or to turn off
> > > > the sources. Priority management and interrupt acknowledgment is also
> > > > controlled by MMIO in the presenter sub-engine.
> > > > 
> > > > These MMIO regions are exposed to guests in QEMU with a set of 'ram
> > > > device' memory mappings, similarly to VFIO, and the VMAs are populated
> > > > dynamically with the appropriate pages using a fault handler.
> > > > 
> > > > But, these regions are an issue for migration. We need to discard the
> > > > associated RAMBlocks from the RAM state on the source VM and let the
> > > > destination VM rebuild the memory mappings on the new host in the
> > > > post_load() operation just before resuming the system.
> > > > 
> > > > To achieve this goal, the following introduces a new RAMBlock flag
> > > > RAM_MIGRATABLE which is updated in the vmstate_register_ram() and
> > > > vmstate_unregister_ram() routines. This flag is then used by the
> > > > migration to identify RAMBlocks to discard on the source. Some checks
> > > > are also performed on the destination to make sure nothing invalid was
> > > > sent.
> > > 
> > > I think in theory this should Just Work for allowing us to
> > > enable migration when the xilinx-spips device is using its
> > > execute-from-mmio feature (we would just need to remove the
> > > code that puts in the migration blocker).
> > > 
> > > Xilinx folks -- do you have a test image for a board that uses
> > > xilinx-spips and exercises the execute-from-mmio code, that
> > > we can use to test migration/vmsave with?
> > 
> > CC:ing Fred
> > 
> > I got an image from Fred a while back ago, I probably still have it
> > somewhere but I've totally forgotten the name for it.
> > 
> > Fred, do you have the image or roughly remember the filename?
> > 
> > Cheers,
> > Edgar
> > 
> 
> Edgar,
> 
> That was a while ago! I don't recall the name sorry for that!
> 
> In the worse case maybe building and putting an u-boot binary for
> zynq in the SPIs will do the job?
> 

Hi again,

I've found the test-case and it still runs OK. Who should I send the
tarball to? 

Cédric Le Goater <address@hidden>
Peter Maydell <address@hidden>

Anyone else who needs it?
Just let me know and I'll email it outside of the mailing list.

Cheers,
Edgar



reply via email to

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