From: Shenming Lu <lushenming@huawei.com>
To: Marc Zyngier <maz@kernel.org>, Eric Auger <eric.auger@redhat.com>,
"Will Deacon" <will@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<kvmarm@lists.cs.columbia.edu>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>,
<lushenming@huawei.com>
Subject: [PATCH v4 0/6] KVM: arm64: Add VLPI migration support on GICv4.1
Date: Sat, 13 Mar 2021 16:38:54 +0800 [thread overview]
Message-ID: <20210313083900.234-1-lushenming@huawei.com> (raw)
Hi,
In GICv4.1, migration has been supported except for (directly-injected)
VLPI. And GICv4.1 Spec explicitly gives a way to get the VLPI's pending
state (which was crucially missing in GICv4.0). So we make VLPI migration
capable on GICv4.1 in this series.
In order to support VLPI migration, we need to save and restore all
required configuration information and pending states of VLPIs. But
in fact, the configuration information of VLPIs has already been saved
(or will be reallocated on the dst host...) in vgic(kvm) migration.
So we only have to migrate the pending states of VLPIs specially.
Below is the related workflow in migration.
On the save path:
In migration completion:
pause all vCPUs
|
call each VM state change handler:
pause other devices (just keep from sending interrupts, and
such as VFIO migration protocol has already realized it [1])
|
flush ITS tables into guest RAM
|
flush RDIST pending tables (also flush VLPI pending states here)
|
...
On the resume path:
load each device's state:
restore ITS tables (include pending tables) from guest RAM
|
for other (PCI) devices (paused), if configured to have VLPIs,
establish the forwarding paths of their VLPIs (and transfer
the pending states from kvm's vgic to VPT here)
We have tested this series in VFIO migration, and found some related
issues in QEMU [2].
Links:
[1] vfio: UAPI for migration interface for device state:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8a24f3f6e38103b77cf399c38eb54e1219d00d6
[2] vfio: Some fixes and optimizations for VFIO migration:
https://patchwork.ozlabs.org/project/qemu-devel/cover/20210310030233.1133-1-lushenming@huawei.com/
History:
v3 -> v4
- Nit fixes.
- Add a CPU cache invalidation right after unmapping the vPE. (Patch 1)
- Drop the setting of PTZ altogether. (Patch 2)
- Bail out if spot !vgic_initialized(). (in Patch 4)
- Communicate the state change (clear pending_latch) via
vgic_queue_irq_unlock. (in Patch 5)
Thanks a lot for the suggestions from Marc!
v2 -> v3
- Add the vgic initialized check to ensure that the allocation and enabling
of the doorbells have already been done before unmapping the vPEs.
- Check all get_vlpi_state related conditions in save_pending_tables in one place.
- Nit fixes.
v1 -> v2:
- Get the VLPI state from the KVM side.
- Nit fixes.
Thanks,
Shenming
Marc Zyngier (1):
irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
Shenming Lu (4):
irqchip/gic-v3-its: Drop the setting of PTZ altogether
KVM: arm64: GICv4.1: Add function to get VLPI state
KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables
KVM: arm64: GICv4.1: Give a chance to save VLPI state
Zenghui Yu (1):
KVM: arm64: GICv4.1: Restore VLPI pending state to physical side
.../virt/kvm/devices/arm-vgic-its.rst | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 6 +-
arch/arm64/kvm/vgic/vgic-v3.c | 66 +++++++++++++++++--
arch/arm64/kvm/vgic/vgic-v4.c | 37 +++++++++++
arch/arm64/kvm/vgic/vgic.h | 1 +
drivers/irqchip/irq-gic-v3-its.c | 21 +++++-
6 files changed, 121 insertions(+), 12 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2021-03-13 8:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 8:38 Shenming Lu [this message]
2021-03-13 8:38 ` [PATCH v4 1/6] irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping Shenming Lu
2021-03-13 8:38 ` [PATCH v4 2/6] irqchip/gic-v3-its: Drop the setting of PTZ altogether Shenming Lu
2021-03-13 8:38 ` [PATCH v4 3/6] KVM: arm64: GICv4.1: Add function to get VLPI state Shenming Lu
2021-03-13 8:38 ` [PATCH v4 4/6] KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables Shenming Lu
2021-03-13 8:38 ` [PATCH v4 5/6] KVM: arm64: GICv4.1: Restore VLPI pending state to physical side Shenming Lu
2021-03-15 8:30 ` Marc Zyngier
2021-03-15 9:11 ` Shenming Lu
2021-03-15 9:20 ` Marc Zyngier
2021-03-15 9:25 ` Shenming Lu
2021-03-15 9:30 ` Marc Zyngier
2021-03-13 8:39 ` [PATCH v4 6/6] KVM: arm64: GICv4.1: Give a chance to save VLPI state Shenming Lu
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=20210313083900.234-1-lushenming@huawei.com \
--to=lushenming@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=maz@kernel.org \
--cc=wanghaibin.wang@huawei.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).