From: Pavel Fedin <p.fedin@samsung.com>
To: qemu-devel@nongnu.org
Cc: 'Peter Maydell' <peter.maydell@linaro.org>,
'Shlomo Pongratz' <shlomopongratz@gmail.com>,
'Shlomo Pongratz' <shlomo.pongratz@huawei.com>
Subject: [Qemu-devel] PING: [RFC PATCH 0/4] GICv3 live migration support
Date: Wed, 07 Oct 2015 10:57:28 +0300 [thread overview]
Message-ID: <014e01d100d5$d08d99f0$71a8cdd0$@samsung.com> (raw)
Knock-knock!
PM: I remember we had a talk that we should settle down on migration data format. Isn't it right
time?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -----Original Message-----
> From: qemu-devel-bounces+p.fedin=samsung.com@nongnu.org [mailto:qemu-devel-
> bounces+p.fedin=samsung.com@nongnu.org] On Behalf Of Pavel Fedin
> Sent: Wednesday, September 30, 2015 5:00 PM
> To: qemu-devel@nongnu.org
> Cc: Peter Maydell; Juan Quintela; Shlomo Pongratz; Shlomo Pongratz; Amit Shah; Diana Craciun
> Subject: [Qemu-devel] [RFC PATCH 0/4] GICv3 live migration support
>
> 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
next reply other threads:[~2015-10-07 7:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 7:57 Pavel Fedin [this message]
2015-10-07 8:02 ` [Qemu-devel] PING: [RFC PATCH 0/4] GICv3 live migration support Peter Maydell
2015-10-07 8:05 ` Pavel Fedin
2015-10-07 8:15 ` Christoffer Dall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='014e01d100d5$d08d99f0$71a8cdd0$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=shlomo.pongratz@huawei.com \
--cc=shlomopongratz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.