Re: [RFC PATCH 2/2] KVM: arm64: vgic-its: Unmap all vPEs on shutdown

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Mon, 2025-06-23 at 18:38 +0200, David Woodhouse wrote:
> On Mon, 2025-06-23 at 14:27 +0100, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > We observed systems going dark on kexec, due to corruption of the new
> > kernel's text (and sometimes the initrd). This was eventually determined
> > to be caused by the vLPI pending tables used by the GIC in the previous
> > kernel, which were not being quiesced properly.
> 
> FWIW this is a previous hack we attempted which *didn't* work. (For
> illustration only; ignore the syscore .kexec hook. We addressed that
> differently in the end with
> https://lore.kernel.org/kexec/20231213064004.2419447-1-jgowans@amazon.com/ )
> 
> At the point where the its_kexec() hook in this patch has completed, we
> poisoned the (ex-) vLPI pending tables and then scanned for corruption
> in them. We saw the same characteristic pattern of corruption which had
> been breaking the next kernel after kexec: 32 bytes copied from offset
> 0 to offset 32 in a page, followed by bytes 0, 1, 32, 33, 34, 35 being
> zeroed.
> 
> Adding a few milliseconds of sleep before the poisoning was enough to
> make the problem go away. As is the patch which calls unmap_all_vpes()
> ∀ kvm.
> 
> Of course, if the GIC were behind an IOMMU as all DMA-capable devices
> should be, this might never have happened...

Any thoughts on this? I'd really appreciate some guidance from Arm on
precisely what is *expected* of the operating system here, to quiesce
the GIC correctly. 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]