On 4/29/22 14:32, Jue Wang wrote: > On Fri, Apr 29, 2022 at 2:10 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: >> I wouldn't go that far. The unaccepted TDX guest memory thing is just >> the obvious one at the moment. There are a whole ton of other guest >> ballooning mechanisms out there and I'm not sure that all of them are >> happy to let you touch ballooned-away memory. > > This type of scanning is intended to be run on the host side. That > should avoid concerns around the guest ballooning or any effects to > the host side reclaim that's based on the guest's working set. Hint: Talk is cheap. Just saying how it is intended doesn't avoid concerns. Saying how it is intended, then backing up that intent with code and deliberate design that matches that intent would be nice. > I don't know why a guest wants to spend its CPU cycles and pollute its > caches etc to run this scanner, anyway. This should be a benefit > provide by the cloud platform transparently to the guest. "This should only be used by and made available by cloud providers!" ... says the cloud provider. ;) Also, who said anything about polluting the caches? Aren't there lots of reasons for a memory poison detector to intentionally not use the caches? First, you really *do* always want to go to memory. That's kinda the point. If this code hits the caches, it's kinda pointless. Second, you want this code to have a low profile. Not polluting the caches seems like a good way to have a low profile. >> But, the bigger issue is that those cases had not even been considered. >> It means that there is a *LOT* of homework needed to seek out and cover >> all the other weird cases. >> >> I also think the proposed ABI -- exposing physical addresses to >> userspace as a part of the design -- is an utter non-starter. > > This can be addressed with a different design.
