[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4892d4cb7fea466fd82bcaf72ad3b29d28ce778.camel@intel.com>
Date: Tue, 7 May 2024 23:01:42 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "Zhao, Yan Y" <yan.y.zhao@...el.com>,
"michael.roth@....com" <michael.roth@....com>, "Yamahata, Isaku"
<isaku.yamahata@...el.com>
Subject: Re: [PATCH v5 07/17] KVM: x86: add fields to struct kvm_arch for CoCo
features
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. 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. 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@intel.com/
Powered by blists - more mailing lists