On Sat, Apr 02, 2022, Kai Huang wrote: > On Fri, 2022-04-01 at 14:08 +0000, Sean Christopherson wrote: > > On Fri, Apr 01, 2022, Kai Huang wrote: > > > On Fri, 2022-03-04 at 11:48 -0800, isaku.yamahata@xxxxxxxxx wrote: > > > > From: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> > > > > > > > > In the existing x86 KVM MMU code, there is already max_level member in > > > > struct kvm_page_fault with KVM_MAX_HUGEPAGE_LEVEL initial value. The KVM > > > > page fault handler denies page size larger than max_level. > > > > > > > > Add per-VM member to indicate the allowed maximum page size with > > > > KVM_MAX_HUGEPAGE_LEVEL as default value and initialize max_level in struct > > > > kvm_page_fault with it. > > > > > > > > For the guest TD, the set per-VM value for allows maximum page size to 4K > > > > page size. Then only allowed page size is 4K. It means large page is > > > > disabled. > > > > > > Do not support large page for TD is the reason that you want this change, but > > > not the result. Please refine a little bit. > > > > Not supporting huge pages was fine for the PoC, but I'd prefer not to merge TDX > > without support for huge pages. Has any work been put into enabling huge pages? > > If so, what's the technical blocker? If not... > > Hi Sean, > > Is there any reason large page support must be included in the initial merge of > TDX? Large page is more about performance improvement I think. Given this > series is already very big, perhaps we can do it later. I'm ok punting 1gb for now, but I want to have a high level of confidence that 2mb pages will work without requiring significant churn in KVM on top of the initial TDX support. I suspect gaining that level of confidence will mean getting 95%+ of the way to a fully working code base. IIRC, 2mb wasn't expected to be terrible, it was 1gb support where things started to get messy.
