From: "Huang, Kai" <kai.huang@intel.com>
To: "Gao, Chao" <chao.gao@intel.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"bp@alien8.de" <bp@alien8.de>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
"nikunj@amd.com" <nikunj@amd.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] KVM: x86: Reject KVM_SET_TSC_KHZ VM ioctl when vCPU has been created
Date: Fri, 11 Jul 2025 02:46:11 +0000 [thread overview]
Message-ID: <02ee140496680e9e3d364dc13f98d472f3b4d028.camel@intel.com> (raw)
In-Reply-To: <aHB0M/aJwzuqYBG4@intel.com>
On Fri, 2025-07-11 at 10:17 +0800, Chao Gao wrote:
> > AFAICT the actual updating of kvm->arch.default_tsc_khz needs to be in the
> > kvm->lock mutex too.
>
> Yep.
>
> > Please let me know if you found any issue?
> >
> > diff --git a/Documentation/virt/kvm/api.rst
> > b/Documentation/virt/kvm/api.rst
> > index 43ed57e048a8..86ea1e2b2737 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -2006,7 +2006,7 @@ frequency is KHz.
> >
> > If the KVM_CAP_VM_TSC_CONTROL capability is advertised, this can also
> > be used as a vm ioctl to set the initial tsc frequency of subsequently
> > -created vCPUs.
> > +created vCPUs. It must be called before any vCPU is created.
>
> ^^ remove one space here.
OK.
>
> "must be" sounds like a mandatory action, but IIUC the vm ioctl is optional for
> non-CC VMs. I'm not sure if this is just a problem of my interpretation.
The context of that paragraph has "can also be used ...", so to me it's
implied that "if it is called", i.e., it's implied that it is optional for
non-CC VMs.
>
> To make the API documentation super clear, how about:
>
> If the KVM_CAP_VM_TSC_CONTROL capability is advertised, this can also
> be used as a vm ioctl to set the initial tsc frequency of vCPUs before
> any vCPU is created. Attempting to call this vm ioctl after vCPU creation
> will return an EINVAL error.
I am not sure we need to mention -EINVAL. This IOCTL is already returning
-EINVAL for other errors (when invalid user_tsc_khz is supplied).
IMHO: Userspace should just care about whether success or not. Being
explicit is good, but sometimes it's better to have some room here.
But I'll let Sean/Paolo to decide.
>
> >
> > 4.56 KVM_GET_TSC_KHZ
> > --------------------
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 2806f7104295..4051c0cacb92 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -7199,9 +7199,12 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned
> > int ioctl, unsigned long arg)
> > if (user_tsc_khz == 0)
> > user_tsc_khz = tsc_khz;
> >
> > - WRITE_ONCE(kvm->arch.default_tsc_khz, user_tsc_khz);
> > - r = 0;
> > -
> > + mutex_lock(&kvm->lock);
> > + if (!kvm->created_vcpus) {
> > + WRITE_ONCE(kvm->arch.default_tsc_khz,
> > user_tsc_khz);
> > + r = 0;
> > + }
> > + mutex_unlock(&kvm->lock);
>
> LGTM.
>
> > goto out;
> > }
> > case KVM_GET_TSC_KHZ: {
next prev parent reply other threads:[~2025-07-11 2:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 5:37 [PATCH 0/2] Improve KVM_SET_TSC_KHZ handling for CoCo VMs Kai Huang
2025-07-09 5:37 ` [PATCH 1/2] KVM: x86: Reject KVM_SET_TSC_KHZ vCPU ioctl for TSC protected guest Kai Huang
2025-07-09 6:40 ` Xiaoyao Li
2025-07-09 8:39 ` Nikunj A. Dadhania
2025-07-10 22:52 ` Huang, Kai
2025-07-11 6:22 ` Nikunj A Dadhania
2025-07-13 7:27 ` Huang, Kai
2025-07-09 5:38 ` [PATCH 2/2] KVM: x86: Reject KVM_SET_TSC_KHZ VM ioctl when vCPU has been created Kai Huang
2025-07-09 6:40 ` Xiaoyao Li
2025-07-09 8:34 ` Chao Gao
2025-07-09 13:55 ` Sean Christopherson
2025-07-10 22:53 ` Huang, Kai
2025-07-11 0:24 ` Huang, Kai
2025-07-11 2:17 ` Chao Gao
2025-07-11 2:46 ` Huang, Kai [this message]
2025-07-09 8:51 ` Nikunj A. Dadhania
2025-07-10 22:54 ` Huang, Kai
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=02ee140496680e9e3d364dc13f98d472f3b4d028.camel@intel.com \
--to=kai.huang@intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=xiaoyao.li@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
all inboxes | Powered by JetHome®