From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhHvQ-0002Va-Ch for qemu-devel@nongnu.org; Wed, 30 Sep 2015 10:00:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhHvM-0004hl-W7 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 10:00:04 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:38651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhHvM-0004ef-QX for qemu-devel@nongnu.org; Wed, 30 Sep 2015 10:00:00 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NVH00ENMTJVSKA0@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 30 Sep 2015 14:59:55 +0100 (BST) From: Pavel Fedin Date: Wed, 30 Sep 2015 16:59:46 +0300 Message-id: Subject: [Qemu-devel] [RFC PATCH 0/4] GICv3 live migration support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , Juan Quintela , Shlomo Pongratz , Shlomo Pongratz , Amit Shah , Diana Craciun This series introduces support for GICv3 live migration. It is based on kernel API which is not released yet, therefore i post it as an RFC. Kernel patches which implement this functionality are: - [PATCH v4 0/7] KVM: arm64: Implement API for vGICv3 live migration http://www.spinics.net/lists/kvm/msg121588.html The main purpose of this RFC is to agree on GICv3 state data format, because software implementation of GICv3 is also going to use it. In order to simplify GICv3 software emulation development, part 1 of this patchset can be accepted right now, without waiting for the kernel part. The second question which should be addressed is how to correctly describe bitfields in vmstate. Bitfields are used by this code in order to reflect per-CPU interrupt status. qemu defines bitfields as arrays of 'long', therefore element length can be different on different systems. Our vmstate macros support only types with fixed size, like UINT64 and UINT32. In order to work around this problem, i relied on __SIZEOF_LONG__ definition. However, i suppose, it is gcc-specific and this approach is wrong for mainstream, therefore i'd like to discuss how this could be done better. Since 'long' maps to something, i think that adding a specific code for it would be too much anyway. May be add configure test for sizeof(long) ? Pavel Fedin (4): hw/intc/arm_gicv3_common: Add state information kernel: Add definitions for GICv3 attributes hw/intc/arm_gicv3_kvm: Implement get/put functions hw/intc/arm_gicv3_common: Add vmstate descriptors hw/intc/arm_gicv3_common.c | 199 ++++++++++++++++++- hw/intc/arm_gicv3_kvm.c | 391 ++++++++++++++++++++++++++++++++++++- hw/intc/gicv3_internal.h | 152 ++++++++++++++ include/hw/intc/arm_gicv3_common.h | 76 +++++++ linux-headers/asm-arm64/kvm.h | 10 +- 5 files changed, 821 insertions(+), 7 deletions(-) create mode 100644 hw/intc/gicv3_internal.h -- 2.4.4