From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dX8y5-0007q0-Fb for qemu-devel@nongnu.org; Mon, 17 Jul 2017 12:33:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dX8y4-0003UR-KP for qemu-devel@nongnu.org; Mon, 17 Jul 2017 12:33:57 -0400 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:35932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dX8y4-0003TN-D5 for qemu-devel@nongnu.org; Mon, 17 Jul 2017 12:33:56 -0400 Received: by mail-wm0-x22c.google.com with SMTP id t70so20763936wmt.1 for ; Mon, 17 Jul 2017 09:33:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1497462353-3432-1-git-send-email-edgar.iglesias@gmail.com> References: <1497462353-3432-1-git-send-email-edgar.iglesias@gmail.com> From: Peter Maydell Date: Mon, 17 Jul 2017 17:33:34 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" 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: QEMU Developers , Paolo Bonzini , Richard Henderson , Edgar Iglesias , KONRAD Frederic , "Dr. David Alan Gilbert" 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