[PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags

[Jason Gunthorpe]

On Tue, Apr 22, 2025 at 05:50:32PM +0100, Catalin Marinas wrote:

> So, for the above, the VMM needs to know that it somehow got into such
> situation. If it knows the device (VFIO) capabilities and that the user
> mapping is Cacheable, coupled with the new KVM CAP, it can infer that
> Stage 2 will be S2FWB, no need for a memory slot flag.

So long as the memslot creation fails for cachable PFNMAP without
S2FWB the VMM is fine. qemu will begin its first steps to startup the
migration destination and immediately fail. The migration will be
aborted before it even gets started on the source side.

As I said before, the present situation requires the site's
orchestration to manage compatibility for live migration of VFIO
devices. We only expect that the migration will abort early if the
site has made a configuration error.

> have such information, maybe a new memory slot flag can be used to probe
> what Stage 2 mapping is going to be: ask for KVM_MEM_PFNMAP_WB. If it
> fails, Stage 2 is Device/NC and can attempt again with the WB flag.
> It's a bit of a stretch for the KVM API but IIUC there's no option to
> query the properties of a memory slot.

I don't know of any use case for something like this. If VFIO gives
the VMM a cachable mapping there is no fallback to WB.

The operator could use a different VFIO device, one that doesn't need
cachable, but the VMM can't flip the VFIO device between modes on the
fly.

Jason