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

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

* KONRAD Frederic (frederic.konrad@adacore.com) wrote:
> 
> 
> On 07/17/2017 07:27 PM, Edgar E. Iglesias 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?
> > 
> > Cheers,
> > Edgar
> > 
> 
> Hi All,
> 
> Yes Edgar is right, they don't need to be migrated (as the old
> Xilinx SPI cache).
> And it will be the case for all the other stuff using this as
> well.
> 
> Maybe we can simply drop the region before the migration?

Dont forget the VM is still running during migration, so you
can't drop anything that's needed for it to be able to execute.

Dave

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