kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);
 }


  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).