From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXBE8-0001lo-Qa for qemu-devel@nongnu.org; Mon, 17 Jul 2017 14:58:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dXBE5-0002rm-Gk for qemu-devel@nongnu.org; Mon, 17 Jul 2017 14:58:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54604) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dXBE5-0002r3-7Z for qemu-devel@nongnu.org; Mon, 17 Jul 2017 14:58:37 -0400 Date: Mon, 17 Jul 2017 19:58:31 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20170717185830.GD31820@work-vm> References: <1497462353-3432-1-git-send-email-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PULL v1 0/7] MMIO Exec pull request List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: Peter Maydell , QEMU Developers , Paolo Bonzini , Richard Henderson , KONRAD Frederic , quintela@redhat.com * Edgar E. Iglesias (edgar.iglesias@gmail.com) wrote: > On Mon, Jul 17, 2017 at 11:33 PM, Peter Maydell > wrote: > > > On 14 June 2017 at 18:45, Edgar E. Iglesias > > wrote: > > > From: "Edgar E. Iglesias" > > > 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