On Tue, May 07, 2024, Rick P Edgecombe wrote: > On Mon, 2024-04-08 at 18:21 -0700, Sean Christopherson wrote: > > > - Give other name for this check like zap_from_leafs (or better name?) > > > The implementation is same to kvm_gfn_shared_mask() with comment. > > > - Or we can add a boolean variable to struct kvm > > > > If we _don't_ hardcode the behavior, a per-memslot flag or a per-VM > > capability (and thus boolean) is likely the way to go. My off-the-cuff > > vote is probably for a per-memslot flag. > > Hi Sean, > > Can you elaborate on the reason for a per-memslot flag? We are discussing this > design point internally, and also the intersection with the previous attempts to > do something similar with a per-vm flag[0]. > > I'm wondering if the intention is to try to make a memslot flag, so it can be > expanded for the normal VM usage. Sure, I'll go with that answer. Like I said, off-the-cuff. There's no concrete motiviation, it's more that _if_ we're going to expose a knob to userspace, then I'd prefer to make it as precise as possible to minimize the changes of KVM ending up back in ABI hell again. > Because the discussion on the original attempts, it seems safer to keep this > behavior more limited (TDX only) for now. And for TDX's usage a struct kvm > bool fits best because all memslots need to be set to zap_leafs_only = true, > anyway. No they don't. They might be set that way in practice for QEMU, but it's not strictly required. E.g. nothing would prevent a VMM from exposing a shared-only memslot to a guest. The memslots that burned KVM the first time around were related to VFIO devices, and I wouldn't put it past someone to be crazy enough to expose an passhtrough an untrusted device to a TDX guest. > It's simpler for userspace, and less possible situations to worry about for KVM. > > [0] https://lore.kernel.org/kvm/20200703025047.13987-1-sean.j.christopherson@xxxxxxxxx/
