From: Isaku Yamahata <isaku.yamahata@intel.com>
To: "Nikunj A. Dadhania" <nikunj@amd.com>
Cc: Isaku Yamahata <isaku.yamahata@intel.com>,
kvm@vger.kernel.org, pbonzini@redhat.com,
Sean Christopherson <seanjc@google.com>,
chao.gao@intel.com, rick.p.edgecombe@intel.com,
yan.y.zhao@intel.com, linux-kernel@vger.kernel.org,
isaku.yamahata@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
isaku.yamahata@linux.intel.com
Subject: Re: [PATCH 0/2] KVM: kvm-coco-queue: Support protected TSC
Date: Thu, 21 Nov 2024 15:32:40 -0800 [thread overview]
Message-ID: <Zz/DGOoo/mEvULiG@ls.amr.corp.intel.com> (raw)
In-Reply-To: <c4df36dc-9924-e166-ec8b-ee48e4f6833e@amd.com>
On Mon, Oct 14, 2024 at 08:17:19PM +0530,
"Nikunj A. Dadhania" <nikunj@amd.com> wrote:
> > Solution
> > --------
> > The solution is to keep the KVM TSC offset/multiplier the same as the value of
> > the TDX module somehow. Possible solutions are as follows.
> > - Skip the logic
> > Ignore (or don't call related functions) the request to change the TSC
> > offset/multiplier.
> > Pros
> > - Logically clean. This is similar to the guest_protected case.
> > Cons
> > - Needs to identify the call sites.
> >
> > - Revert the change at the hooks after TSC adjustment
> > x86 KVM defines the vendor hooks when the TSC offset/multiplier are
> > changed. The callback can revert the change.
> > Pros
> > - We don't need to care about the logic to change the TSC offset/multiplier.
> > Cons:
> > - Hacky to revert the KVM x86 common code logic.
> >
> > Choose the first one. With this patch series, SEV-SNP secure TSC can be
> > supported.
>
> I am not sure how will this help SNP Secure TSC, as the GUEST_TSC_OFFSET and
> GUEST_TSC_SCALE are only available to the guest.
Although Xiaoyao mentioned KVM emulated timer, let me clarify it.
I think the following is common for SEV-SNP and TDX.
The issue is with guest MSR_IA32_TSC_DEADLINE (and guest local APIC Timer
Initial Count Register). As long as I understand according to the public
documentation, the SEV-SNP hardware (or the TDX module) doesn't virtualize it so
that the VMM (KVM) has to emulate it.
The KVM uses the host timer(vcpu->arch.apic.lapic_timer) and inject timer
interrupt withit. KVM tracks TSC multiplier/offset to calculate the host
TSC timeout value based on them.
The KVM multiplier and offset must match with the values the hardware
(or the TDX module) thinks. If they don't match, the KVM tsc deadline timer
(or local APIC timer) emulation is inaccurate. Timer interrupt is injected
Late or early.
KVM has several points to change tsc multiplier/offset from the original value.
This patch series is to prevent KVM from modifying TSC multipler/offset.
In reality, it's difficult to notice that the timer interrupt is injected late
or early like several miliseconds due to vCPU scheduling. The injecting timer
interrupt always late harms time sensitive workload (e.g. heart beat) in guest
as Marcelo noticed.
Thanks,
--
Isaku Yamahata <isaku.yamahata@intel.com>
next prev parent reply other threads:[~2024-11-21 23:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-12 7:55 [PATCH 0/2] KVM: kvm-coco-queue: Support protected TSC Isaku Yamahata
2024-10-12 7:55 ` [PATCH 1/2] KVM: x86: Push down setting vcpu.arch.user_set_tsc Isaku Yamahata
2024-10-12 7:55 ` [PATCH 2/2] KVM: x86: Don't allow tsc_offset, tsc_scaling_ratio to change Isaku Yamahata
2024-10-14 15:48 ` Edgecombe, Rick P
2024-11-21 23:50 ` Isaku Yamahata
2025-03-12 12:24 ` Paolo Bonzini
2025-03-14 0:39 ` Isaku Yamahata
2024-10-14 14:47 ` [PATCH 0/2] KVM: kvm-coco-queue: Support protected TSC Nikunj A. Dadhania
2024-10-25 16:24 ` Marcelo Tosatti
2024-10-27 14:06 ` Xiaoyao Li
2024-10-28 16:42 ` Marcelo Tosatti
2024-10-29 4:04 ` Nikunj A. Dadhania
2024-10-29 13:44 ` Marcelo Tosatti
2024-10-28 12:48 ` Nikunj A. Dadhania
2024-11-21 23:32 ` Isaku Yamahata [this message]
2025-03-12 1:13 ` Marcelo Tosatti
2025-03-14 0:43 ` Isaku Yamahata
2025-03-12 12:22 ` Paolo Bonzini
2025-03-12 13:07 ` Nikunj A. Dadhania
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=Zz/DGOoo/mEvULiG@ls.amr.corp.intel.com \
--to=isaku.yamahata@intel.com \
--cc=chao.gao@intel.com \
--cc=isaku.yamahata@gmail.com \
--cc=isaku.yamahata@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.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