From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "seanjc@google.com" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>,
"michael.roth@amd.com" <michael.roth@amd.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [PATCH v5 07/17] KVM: x86: add fields to struct kvm_arch for CoCo features
Date: Wed, 8 May 2024 15:04:12 +0000 [thread overview]
Message-ID: <cf75bf92f096f4303a911ca5fd119fe765a618e2.camel@intel.com> (raw)
In-Reply-To: <ZjuOUzhVIgkAQXmf@google.com>
On Wed, 2024-05-08 at 07:38 -0700, Sean Christopherson wrote:
> > Ok, thanks for clarification. So it's more of a strategic thing to move more
> > zapping logic into userspace so the logic can change without introducing
> > kernel
> > regressions.
>
> You're _really_ reading too much into my suggestion. As above, my suggestion
> was very spur of the momemnt. I haven't put much thought into the tradeoffs
> and
> side effects.
I'm not taking it as a mandate. Just trying to glean your insights. That said,
I'm really on the fence and so leaning on your intuition as the tie breaker.
For TDX's usage a struct kvm bool seems simpler code wise in KVM, and for
userspace. But the zapping logic as ABI problem seems like a reasonable thing to
think about while we are designing new ABI. Of course, it also means KVM has to
be responsible now for safely zapping memory from a variety of userspace
algorithms. So it somewhat makes KVM's job easier, and somewhat makes it harder.
The real issue might be that that problem was never debugged. While there is no
evidence it will affect TDXs, it remains a possibility. But we can't do the zap
roots thing for TDX, so in the end the ABI design will not affect TDX exposure
either way. But making it a normal feature will affect exposure for normal VMs.
So we are also balancing ABI flexibility with exposure to that specific bug.
next prev parent reply other threads:[~2024-05-08 15:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 12:13 [PATCH v5 00/17] KVM: SEV: allow customizing VMSA features Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 01/17] KVM: SVM: Invert handling of SEV and SEV_ES feature flags Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 02/17] KVM: SVM: Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 03/17] KVM: x86: use u64_to_user_ptr() Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 04/17] KVM: introduce new vendor op for KVM_GET_DEVICE_ATTR Paolo Bonzini
2024-04-04 21:30 ` Isaku Yamahata
2024-04-04 12:13 ` [PATCH v5 05/17] KVM: SEV: publish supported VMSA features Paolo Bonzini
2024-04-04 21:32 ` Isaku Yamahata
2024-04-04 12:13 ` [PATCH v5 06/17] KVM: SEV: store VMSA features in kvm_sev_info Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 07/17] KVM: x86: add fields to struct kvm_arch for CoCo features Paolo Bonzini
2024-04-04 21:39 ` Isaku Yamahata
2024-04-05 23:01 ` Edgecombe, Rick P
2024-04-09 1:21 ` Sean Christopherson
2024-04-09 14:01 ` Edgecombe, Rick P
2024-04-09 14:43 ` Paolo Bonzini
2024-04-09 15:26 ` Sean Christopherson
2024-05-07 23:01 ` Edgecombe, Rick P
2024-05-08 0:21 ` Sean Christopherson
2024-05-08 1:19 ` Edgecombe, Rick P
2024-05-08 14:38 ` Sean Christopherson
2024-05-08 15:04 ` Edgecombe, Rick P [this message]
2024-04-04 12:13 ` [PATCH v5 08/17] KVM: x86: Add supported_vm_types to kvm_caps Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 09/17] KVM: SEV: introduce to_kvm_sev_info Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 10/17] KVM: SEV: define VM types for SEV and SEV-ES Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 11/17] KVM: SEV: sync FPU and AVX state at LAUNCH_UPDATE_VMSA time Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 12/17] KVM: SEV: introduce KVM_SEV_INIT2 operation Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 13/17] KVM: SEV: allow SEV-ES DebugSwap again Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 14/17] selftests: kvm: add tests for KVM_SEV_INIT2 Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 15/17] selftests: kvm: switch to using KVM_X86_*_VM Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 16/17] selftests: kvm: split "launch" phase of SEV VM creation Paolo Bonzini
2024-04-04 12:13 ` [PATCH v5 17/17] selftests: kvm: add test for transferring FPU state into VMSA Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf75bf92f096f4303a911ca5fd119fe765a618e2.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).