On Tue, 2024-11-12 at 14:52 +0000, David Hildenbrand wrote: > On 12.11.24 15:40, Patrick Roy wrote: >> I remember talking to someone at some point about whether we could reuse >> the proc-local stuff for guest memory, but I cannot remember the outcome >> of that discussion... (or maybe I just wanted to have a discussion about >> it, but forgot to follow up on that thought?). I guess we wouldn't use >> proc-local _allocations_, but rather just set up proc-local mappings of >> the gmem allocations that have been removed from the direct map. > > Yes. And likely only for memory we really access / try access, if possible. Well, if we start on-demand mm-local mapping the things we want to access, we're back in TLB flush hell, no? And we can't know ahead-of-time what needs to be mapped, so everything would need to be mapped (unless we do something like mm-local mapping a page on first access, and then just never unmapping it again, under the assumption that establishing the mapping won't be expensive) >> >> I'm wondering, where exactly would be the differences to Sean's idea >> about messing with the CR3 register inside KVM to temporarily install >> page tables that contain all the gmem stuff, conceptually? Wouldn't we >> run into the same interrupt problems that Sean foresaw for the CR3 >> stuff? (which, admittedly, I still don't quite follow what these are :( >> ). > > I'd need some more details on that. If anything would rely on the direct > mapping (from IRQ context?) than ... we obviously cannot remove the > direct mapping :) I've talked to Fares internally, and it seems that generally doing mm-local mappings of guest memory would work for us. We also figured out what the "interrupt problem" is, namely that if we receive an interrupt while executing in a context that has mm-local mappings available, those mappings will continue to be available while the interrupt is being handled. I'm talking to my security folks to see how much of a concern this is for the speculation hardening we're trying to achieve. Will keep you in the loop there :) > -- > Cheers, > > David / dhildenb > Best, Patrick
