[RFC] ARM vGIC-ITS tables serialization when running protected VMs

[David Woodhouse]

On Tue, 2025-04-22 at 11:47 +0100, David Woodhouse wrote:
> 
> I think it's much better just to let KVM pass the state to userspace
> for migration, just like KVM does for almost all *other* state.

Even without confidential VMs, we've just found another reason to avoid
this abomination where KVM scribbles its state into guest memory
instead of passing it up to userspace for serialization like normal KVM
code does.

When a guest resumes from hibernation, it comes up into a 'boot kernel'
as normal, and that kernel then finds the hibernation signature in its
swap space and restores the original running kernel. That transition
isn't a kexec; it takes yet another slightly different path through the
PM suspend and resume code (in the boot and the resumed kernel, resp.).

We've found that this seems to leave the GIC in the 'wrong' state
somehow. A subsequent KVM serialization for LU/LM causes memory
corruption, because KVM scribbles its state to addresses in guest
memory that the resumed kernel does not expect, causing subsequent
guest crashes.

It's probably going to turn out to be something we can blame on the
guest kernel, just as we can blame the memory corruption addressed by
https://lore.kernel.org/all/20250623132714.965474-2-dwmw2@infradead.org/
on the kernel — but ultimately, it's all just working around the
insanity of the GIC's proclivity for IOMMU-unprotected DMA.

Just because the hardware specification was designed by badgers, that
doesn't mean that KVM has to follow its lead into the host userspace
APIs.

Let's have a way for userspace to serialize GIC state like a normal KVM
device, to a userspace buffer. As Ilias was proposing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5069 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250626/53fa5389/attachment.p7s>