On Tue, Jun 24, 2025 at 05:44:17AM +0800, Edgecombe, Rick P wrote: > On Fri, 2025-06-20 at 09:31 -0700, Sean Christopherson wrote: > > > On Wed, Jun 18, 2025, Yan Zhao wrote: > > > > > when an EPT violation carries an ACCEPT level info > > > > > KVM maps the page at map level <= the specified level. > > > > > > No. I want KVM to map at the maximal level KVM supports, irrespective of what > > > the guest's ACCEPT level says. I.e. I want KVM to be able to completely ignore > > > the ACCEPT level. > > This is what I was thinking, but I'm starting to think it might not be a good > idea. > > The PAGE_SIZE_MISMATCH error code asymmetry is indeed weird. But "accepted" is > in some important ways a type of permission that is controllable by both the > guest and host. To change the ABI and guests such that the permission is still > controlled by the host and guest, but the allowed granularity is only > controllable by the host, feels wrong in a couple ways. > > First, it turns host mapping details into guest ABI that could break guests that > rely on it. Second, it bets that there will never be a need for guests to set > the accept state on a specific smaller granularity. Otherwise, this path would > just be a temporary shortcut and not about components imposing things that are > none of their business. > > Instead I think the two impositions that matter here are: > 1. TDX requires size to be passed through the generic fault handler somehow. > 2. TDX demote is hard to make work under mmu read lock (already working on this > one) > > Sean, were the two options for (1) really that bad? Or how do you think about > changing directions in general and we can try to find some other options? > > On the subject of alternates to (1). I wonder if the ugly part is that both of > the options sort of break the KVM model where the TDP is not the real backing > state. TDG.MEM.PAGE.ACCEPT is kind of two things, changing the "permission" of > the memory *and* the mapping of it. TDX module asks, map this at this page size > so that I can map it at the right permission. KVM would rather learn that the > permission from the backing GPA info (memslots, etc) and then map it at it's > correct page size. Like what happens with kvm_lpage_info->disallow_lpage. Could we provide the info via the private_max_mapping_level hook (i.e. via tdx_gmem_private_max_mapping_level())? Or what about introducing a vendor hook in __kvm_mmu_max_mapping_level() for a private fault? > Maybe we could have EPT violations that contain 4k accept sizes first update the > attribute for the GFN to be accepted or not, like have tdx.c call out to set > kvm_lpage_info->disallow_lpage in the rarer case of 4k accept size? Or something Something like kvm_lpage_info->disallow_lpage would disallow later page promotion, though we don't support it right now. > like that. Maybe set a "accepted" attribute, or something. Not sure if could be Setting "accepted" attribute in the EPT violation handler? It's a little odd, as the accept operation is not yet completed. > done without the mmu write lock... But it might fit KVM better?
