Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Edgar E. Iglesias (edgar.iglesias@gmail.com) wrote:
> On Mon, Jul 17, 2017 at 11:33 PM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
> 
> > On 14 June 2017 at 18:45, Edgar E. Iglesias <edgar.iglesias@gmail.com>
> > wrote:
> > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > Paolo suggested offline that we send a pull request for this series.
> > > Here it is, I've run it through my testsuite + tested the LQSPI testcase
> > > on Zynq.
> >
> > > ----------------------------------------------------------------
> > > mmio-exec.for-upstream
> > >
> > > ----------------------------------------------------------------
> > > KONRAD Frederic (7):
> > >       cputlb: cleanup get_page_addr_code to use VICTIM_TLB_HIT
> > >       cputlb: move get_page_addr_code
> > >       cputlb: fix the way get_page_addr_code fills the tlb
> > >       qdev: add MemoryRegion property
> > >       introduce mmio_interface
> > >       exec: allow to get a pointer for some mmio memory region
> > >       xilinx_spips: allow mmio execution
> >
> > Hi Edgar -- can you or Fred explain how this code interacts with
> > VM migration? The mmio-interface device creates a RAM memory
> > region with memory_region_init_ram_ptr(), but it doesn't call
> > vmstate_register_ram(). On the other hand the core migration code
> > will try to migrate the contents of the RAMBlock anyway, just
> > without a name.
> >
> > It's not clear to me how this works, and it would be nice to
> > get it clear so that we can make any necessary fixes before the
> > 2.10 release hits and we lose the opportunity to make any
> > migration-compatibility-breaking changes.
> >
> > thanks
> > -- PMM
> >
> 
> Hi Peter,
> 
> These temporary regions should be read-only and treated as temporary caches
> AFAIU things.
> I would say that they don't need to be migrated. After migration, the new
> VM will recreate the ram areas from device backing.
> 
> Is there a way we can prevent migration of the RAMBlock?

Not yet, I think we'd have to:
   a) Add a flag to the RAMBlock
   b) Set it/clear it on registration
   c) Have a RAMBLOCK_FOREACH_MIGRATABLE macro
   d) Replace all of the RAMBLOCK_FOREACH (and the couple of hand coded
   cases) with the RAMBLOCK_FOREACH_MIGRATABLE
   e) Worry about the corner cases!

I've got a few worries about what happens when the kernel tries to
do dirty yncing - I'm not sure if we have to change anything on that
interface to skip those RAMBlocks.

Dave

> Cheers,
> Edgar
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK