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

[David Woodhouse]

On Tue, 2025-04-15 at 10:44 +0100, David Woodhouse wrote:
>  
> 
> > > Another issue is that it's actually hard for the lowvisor to know where these
> > > tables live without trusting the EL1 host which virtualizes the ITS. It is
> > > especially hard knowing the locations of the ITTs (compared to
> > > Collection/Device tables) because that probably means having to parse the ITS
> > > command queue from EL2 which is complex and undesirable.
> > > 
> > > # An alternative: Serializing ITTs into a userspace buffer
> > 
> > NAK.
> > 
> > Share the page-aligned memory with the rest of the hypervisor, and use
> > the existing API.
> 
> That seems like a bad choice. All this is just using guest memory to
> store KVM's state.
> 
> Yes, the guest provides a buffer which the virtual hardware *may* use
> if it wants, but with no IOMMU or access control defined in the
> specification.
> 
> It seems like it would be much cleaner just to let KVM pass its state
> up to userspace for serialization like we do for all *other* KVM state,
> which is what Ilias is proposing.

Ping?

Redefining the GIC specification to implicitly share whole pages with
the hypervisor in a protected guest, when they happen to have an ITT
somewhere inside the page, seems like a very bad idea. Did you have
some proposed wording for the specification update though, if that's
the approach you're proposing?

And *implementing* it by making the lowvisor snoop on the ITS command
queue is also awful.

Putting the GIC behind an IOMMU so that page-granular access control
can be done in a sane way might have made sense, as this is
conceptually DMA. The GIC specification made the same mistake that
early virtio made, and which we *should* have learned from. But like
virtio, I think it's too late to fix that without a time machine.

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.

-------------- 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/20250422/20804309/attachment.p7s>