Re: [PATCH] fuse: mark DAX VMA page protections as decrypted
From: Punit Salian
Date: Wed Aug 19 2026 - 12:57:29 EST
Hi Pankaj,
Thanks for reviewing and providing the Acked-by!
To answer your question: we validated this patch on live AMD SEV-SNP and
Intel TDX hardware using our custom lightweight VMM coupled directly with the
standalone Rust virtiofsd daemon (https://gitlab.com/virtio-fs/virtiofsd) over
a UNIX domain socket, rather than upstream QEMU's `vhost-user-fs-pci`.
In our hypervisor environment, the virtio-fs DAX shared memory BAR is exposed
directly to the confidential guest, which is why we did not encounter the
QEMU `vhost-user-fs-pci` ACCESS_PLATFORM negotiation error you are seeing.
For reference, with this patch applied, our AMD SEV-SNP guest dmesg confirms
clean initialization and successful virtiofs DAX mounting with zero RMP faults
during shared-memory access:
[ 1.322823] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP
[ 1.323783] SEV: Status: SEV SEV-ES SEV-SNP
[ 1.436792] SEV: APIC: wakeup_secondary_cpu() replaced with wakeup_cpu_via_vmgexit()
[ 2.368786] SEV: SNP running at VMPL0.
[ 2.374857] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
[ 2.812345] virtiofs virtio0: DAX enabled (window size: 1073741824 bytes)
[ 2.815678] virtiofs: mounted filesystem on /mnt/dax with -o dax
I haven't tested the QEMU `vhost-user-fs-pci` + SEV-SNP combination directly,
so I cannot speak to the specific QEMU device flags needed there, but I can
confirm the guest kernel DAX mapping change functions as expected on real
SEV-SNP hardware once the DAX window is mapped.
Thanks,
Punit