On 26.04.22 21:39, Dave Hansen wrote: > On 4/26/22 12:23, Jue Wang wrote: >> On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >>> What if you're in a normal (non-TDX) guest and some of the physical >>> address space has been ballooned away? >> >> Accessing to memory that gets ballooned away will cause extra EPT >> violations and have the memory faulted in on the host side, which is >> transparent to the guest. > > Yeah, but it completely subverts the whole purpose of ballooning. In > other words, this is for all intents and purposes also mutually > exclusive with ballooning. Some balloon (or balloon-like) implementations don't support reading memory that's mapped into the direct map. For example, with never virtio-mem devices in the hypervisor, reading unplugged memory can result in undefined behavior (in the worst case, you'll get your VM zapped). Reading random physical memory ranges without further checks is a very bad idea. There are more corner cases, that we e.g., exclude when reading /proc/kcore. Take a look at read_kcore() KCORE_RAM case, where we e.g., exclude reading PageOffline(), is_page_hwpoison() and !pfn_is_ram(). Unaccepted memory might be another case we want to exclude there in the future. I assume something as you imagine could be implemented in user space just by relying on /proc/iomem and /proc/kcore right now in an unsafe way. So you might want something similar, however, obviously without exporting page content to user space and requiring root permissions. -- Thanks, David / dhildenb