On Wed, May 29, 2024 at 09:25:46AM +0200, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On Wed, May 29, 2024 at 4:14 AM Edgecombe, Rick P > <rick.p.edgecombe@xxxxxxxxx> wrote: > > > > On Tue, 2024-05-28 at 19:47 +0200, Paolo Bonzini wrote: > > > On Tue, May 28, 2024 at 6:27 PM Edgecombe, Rick P > > > <rick.p.edgecombe@xxxxxxxxx> wrote: > > > > > I don't see benefit of x86_ops.max_gfn() compared to kvm->arch.max_gfn. > > > > > But I don't have strong preference. Either way will work. > > > > > > > > The non-TDX VM's won't need per-VM data, right? So it's just unneeded extra > > > > state per-vm. > > > > > > It's just a cached value like there are many in the MMU. It's easier > > > for me to read code without the mental overhead of a function call. > > > > Ok. Since this has (optimization) utility beyond TDX, maybe it's worth splitting > > it off as a separate patch? I think maybe we'll pursue this path unless there is > > objection. > > Yes, absolutely. Ok, let me cook an independent patch series for kvm-coco-queue. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>