> Definitely not suggesting to install an invalid pointer anywhere. The
> mapped pointer will still be valid for gmem for example, but the fault
> isn't. We need to differenciate two things (1) virtual address mapping,
> then (2) permission and accesses on the folios / pages of the mapping.
> Here I think it's okay if the host pointer is correctly mapped.
>
> For your private MMIO use case, my question is if there's no host pointer
> to be mapped anyway, then what's the benefit to make the MR to be ram=on?
> Can we simply make it a normal IO memory region? The only benefit of a
The guest access to normal IO memory region would be emulated by QEMU,
while private assigned MMIO requires guest direct access via Secure EPT.
Seems the existing code doesn't support guest direct access if
mr->ram == false:
static void kvm_set_phys_mem(KVMMemoryListener *kml,
MemoryRegionSection *section, bool add)
{
[...]
if (!memory_region_is_ram(mr)) {
if (writable || !kvm_readonly_mem_allowed) {
return;
} else if (!mr->romd_mode) {
/* If the memory device is not in romd_mode, then we actually want
* to remove the kvm memory slot so all accesses will trap. */
add = false;
}
}
[...]
/* register the new slot */
do {
[...]
err = kvm_set_user_memory_region(kml, mem, true);
}
}
> ram=on MR is, IMHO, being able to be accessed as RAM-like. If there's no
> host pointer at all, I don't yet understand how that helps private MMIO
> from working.
I expect private MMIO not accessible from host, but accessible from
guest so has kvm_userspace_memory_region2 set. That means the resolving
of its PFN during EPT fault cannot depends on host pointer.
https://lore.kernel.org/all/20250107142719.179636-1-yilun.xu@xxxxxxxxxxxxxxx/
Thanks,
Yilun
>
> Thanks,
>
> --
> Peter Xu
>
