Re: [PATCH] fuse: mark DAX VMA page protections as decrypted
Punit Salian <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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