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. > > > For TDX it will be based on the shared bit, so we actually already have the > > per- > > vm data we need. So we don't even need both gfn_shared_mask and max_gfn for > > TDX. > > But they are independent, for example AMD placed the encryption bit > highest, then the reduced physical address space bits, then finally > the rest of the gfn. I think it's consistent with the kvm_has_* > approach, to not assume much and just store separate data. I meant for a TDX specific x86_ops implementation we already have the data needed to compute it (gfn_shared_mask - 1). I didn't realize SEV would benefit from this too.
