On Sat, 2024-06-08 at 11:08 +0200, Paolo Bonzini wrote: > > The downside would be wider distribution of the concerns for dealing with > > multiple aliases for a GFN. Currently, the behavior to have multiple aliases > > is > > implemented in core MMU code. While it's fine to pollute tdx.c with TDX > > specific > > knowledge of course, removing the handling of this corner from mmu.c might > > make > > it less understandable for non-tdx readers who are working in MMU code. > > Basically, if a concept fits into some non-TDX abstraction like this, having > > it > > in core code seems the better default to me. > > I am not sure why it's an MMU concept that "if you offset the shared > mappings you cannot implement flush_remote_tlbs_range". It seems more > like, you need to know what you're doing? > > Right now it makes no difference because you don't set the callback; > but if you ever wanted to implement flush_remote_tlbs_range as an > optimization you'd have to remove the condition from the "if". So it's > better not to have it in the first place. Yea that's true. > > Perhaps add a comment instead, like: > > if (!kvm_x86_ops.flush_remote_tlbs_range) > return -EOPNOTSUPP; > > + /* > + * If applicable, the callback should flush GFNs both with and without > + * the direct-mapping bits. > + */ > return static_call(kvm_x86_flush_remote_tlbs_range)(kvm, gfn, nr_pages); Ok, works for me.
