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. >> What does the kernel do when userspace asks it to poke a non-"System >> RAM" address? > > I expect the kernel should reject the request with -EINVAL. Right. Only the kernel has the knowledge of what can actually _be_ scanned. So, why even bother exposing physical addresses to userspace? Why is exposing the actual physical address any better than exposing a cookie? > Just curious, what could be recommendations from Intel's perspective > to make proactively poison detection work on TDX / SEV-SNP? I shouldn't speak for Intel as a whole, but I'll give you my personal perspective. Right now, hosts can't scan TDX private memory, period. If you wanted to do scanning, the guest has to do it or you have to kill the guest and make the memory non-private. Going forward, guest memory scanning could be accomplished by allowing the VMM to migrate guest pages. Let's say you want to scan page "A", you could move A->B and B->A. That would certainly touch the page. This would need to be implemented in the TDX module. Or, the TDX module could have a special call to just touch the page. It would probably also need more work in the TDX module to be able to handle machine checks. I don't think the handling in there is very robust today. It could also be implemented with some new VMM-side ISA which promises to touch the physical memory, but doesn't return any data, ignores the "TD bit" and doesn't do any integrity checking.
