On Wed, Apr 13, 2022 at 5:14 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, Mar 30, 2022, Lai Jiangshan wrote: > > From: Lai Jiangshan <jiangshan.ljs@xxxxxxxxxxxx> > > > > Currently pae_root is special root page, this patch adds facility to > > allow using kvm_mmu_get_page() to allocate pae_root shadow page. > > I don't think this will work for shadow paging. CR3 only has to be 32-byte aligned > for PAE paging. Unless I'm missing something subtle in the code, KVM will incorrectly > reuse a pae_root if the guest puts multiple PAE CR3s on a single page because KVM's > gfn calculation will drop bits 11:5. I forgot about it. > > Handling this as a one-off is probably easier. For TDP, only 32-bit KVM with NPT > benefits from reusing roots, IMO and shaving a few pages in that case is not worth > the complexity. > I liked the one-off idea yesterday and started trying it. But things were not going as smoothly as I thought. There are too many corner cases to cover. Maybe I don't get what you envisioned. one-off shadow pages must not be in the hash, must be freed immediately in kvm_mmu_free_roots(), taken care in kvm_mmu_prepare_zap_page() and so on. When the guest is 32bit, the host has to free and allocate sp every time when the guest changes cr3. It will be a regression when !TDP. one-off shadow pages are too distinguished from others. When using one-off shadow pages, role.passthough can be one bit and be used only for 5-level NPT L0 for 4-level NPT L1, which is neat. And role.pae_root can be removed. I want the newly added shadow pages to fit into the current shadow page management and root management. I'm going to add sp->pae_off (u16) which is 11:5 of the cr3 when the guest is PAE paging. It needs only less than 10 lines of code. Thanks. Lai