Re: [PATCH] fuse: mark DAX VMA page protections as decrypted

[Punit Salian <psalian@google.com>]

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