From: Sean Christopherson <seanjc@google.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: isaku.yamahata@intel.com, pbonzini@redhat.com,
erdemaktas@google.com, vkuznets@redhat.com,
vannapurve@google.com, jmattson@google.com, mlevitsk@redhat.com,
xiaoyao.li@intel.com, chao.gao@intel.com,
rick.p.edgecombe@intel.com, yuan.yao@intel.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V8 1/2] KVM: selftests: Add x86_64 guest udelay() utility
Date: Tue, 11 Jun 2024 15:03:11 -0700 [thread overview]
Message-ID: <ZmjJnzBkOe58fFL6@google.com> (raw)
In-Reply-To: <a44d4534-3ba1-4bee-b06d-bb2a77fe3856@intel.com>
On Tue, Jun 11, 2024, Reinette Chatre wrote:
> > Heh, the docs are stale. KVM hasn't returned an error since commit cc578287e322
> > ("KVM: Infrastructure for software and hardware based TSC rate scaling"), which
> > again predates selftests by many years (6+ in this case). To make our lives
> > much simpler, I think we should assert that KVM_GET_TSC_KHZ succeeds, and maybe
> > throw in a GUEST_ASSERT(thz_khz) in udelay()?
>
> I added the GUEST_ASSERT() but I find that it comes with a caveat (more below).
>
> I plan an assert as below that would end up testing the same as what a
> GUEST_ASSERT(tsc_khz) would accomplish:
>
> r = __vm_ioctl(vm, KVM_GET_TSC_KHZ, NULL);
> TEST_ASSERT(r > 0, "KVM_GET_TSC_KHZ did not provide a valid TSC freq.");
> tsc_khz = r;
>
>
> Caveat is: the additional GUEST_ASSERT() requires all tests that use udelay() in
> the guest to now subtly be required to implement a ucall (UCALL_ABORT) handler.
> I did a crude grep check to see and of the 69 x86_64 tests there are 47 that do
> indeed have a UCALL_ABORT handler. If any of the other use udelay() then the
> GUEST_ASSERT() will of course still trigger, but will be quite cryptic. For
> example, "Unhandled exception '0xe' at guest RIP '0x0'" vs. "tsc_khz".
Yeah, we really need to add a bit more infrastructure, there is way, way, waaaay
too much boilerplate needed just to run a guest and handle the basic ucalls.
Reporting guest asserts should Just Work for 99.9% of tests.
Anyways, is it any less cryptic if ucall_assert() forces a failure? I forget if
the problem with an unhandled GUEST_ASSERT() is that the test re-enters the guest,
or if it's something else.
I don't think we need a perfect solution _now_, as tsc_khz really should never
be 0, just something to not make life completely miserable for future developers.
diff --git a/tools/testing/selftests/kvm/lib/ucall_common.c b/tools/testing/selftests/kvm/lib/ucall_common.c
index 42151e571953..1116bce5cdbf 100644
--- a/tools/testing/selftests/kvm/lib/ucall_common.c
+++ b/tools/testing/selftests/kvm/lib/ucall_common.c
@@ -98,6 +98,8 @@ void ucall_assert(uint64_t cmd, const char *exp, const char *file,
ucall_arch_do_ucall((vm_vaddr_t)uc->hva);
+ ucall_arch_do_ucall(GUEST_UCALL_FAILED);
+
ucall_free(uc);
}
next prev parent reply other threads:[~2024-06-11 22:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 18:25 [PATCH V8 0/2] KVM: x86: Make bus clock frequency for vAPIC timer configurable Reinette Chatre
2024-06-10 18:25 ` [PATCH V8 1/2] KVM: selftests: Add x86_64 guest udelay() utility Reinette Chatre
2024-06-11 0:21 ` Sean Christopherson
2024-06-11 21:33 ` Reinette Chatre
2024-06-11 22:03 ` Sean Christopherson [this message]
2024-06-11 23:07 ` Reinette Chatre
2024-06-12 1:15 ` Sean Christopherson
2024-06-12 17:49 ` Reinette Chatre
2024-06-10 18:25 ` [PATCH V8 2/2] KVM: selftests: Add test for configure of x86 APIC bus frequency Reinette Chatre
2024-06-11 0:51 ` Sean Christopherson
2024-06-11 21:34 ` Reinette Chatre
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=ZmjJnzBkOe58fFL6@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=erdemaktas@google.com \
--cc=isaku.yamahata@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=vannapurve@google.com \
--cc=vkuznets@redhat.com \
--cc=xiaoyao.li@intel.com \
--cc=yuan.yao@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 NNTP newsgroup(s).