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 18:15:09 -0700 [thread overview]
Message-ID: <Zmj2nVhtVoGflaiG@google.com> (raw)
In-Reply-To: <88c65b89-5174-4076-82cd-7852c8c25b66@intel.com>
On Tue, Jun 11, 2024, Reinette Chatre wrote:
> > 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);
> > }
> >
>
> Thank you very much.
>
> With your suggestion an example unhandled GUEST_ASSERT() looks as below.
> It does not guide on what (beyond vcpu_run()) triggered the assert but it
> indeed provides a hint that adding ucall handling may be needed.
>
> [SNIP]
> ==== Test Assertion Failure ====
> lib/ucall_common.c:154: addr != (void *)GUEST_UCALL_FAILED
> pid=16002 tid=16002 errno=4 - Interrupted system call
> 1 0x000000000040da91: get_ucall at ucall_common.c:154
> 2 0x0000000000410142: assert_on_unhandled_exception at processor.c:614
> 3 0x0000000000406590: _vcpu_run at kvm_util.c:1718
> 4 (inlined by) vcpu_run at kvm_util.c:1729
> 5 0x00000000004026cf: test_apic_bus_clock at apic_bus_clock_test.c:115
> 6 (inlined by) run_apic_bus_clock_test at apic_bus_clock_test.c:164
> 7 (inlined by) main at apic_bus_clock_test.c:201
> 8 0x00007fb1d8429d8f: ?? ??:0
> 9 0x00007fb1d8429e3f: ?? ??:0
> 10 0x00000000004027a4: _start at ??:?
> Guest failed to allocate ucall struct
/facepalm
No, it won't work, e.g. relies on get_ucall() being invoked. I'm also being
unnecessarily clever, and missing the obvious, simple solution.
The only reason tests manually handle UCALL_ABORT is because back when it was
added, there was no sprintf support in the guest, i.e. the guest could only spit
out raw information, it couldn't format a human-readable error message. And so
tests manually handled UCALL_ABORT with a custom message.
When we added sprintf support, (almost) all tests moved formatting to the guest
and converged on using REPORT_GUEST_ASSERT(), but we never completed the cleanup
by moving REPORT_GUEST_ASSERT() to common code.
Even more ridiculous is that assert_on_unhandled_exception() is still a thing.
That code exists _literally_ to handle this scenario, where common guest library
code needs to signal a failure.
In short, the right way to resolve this is to have _vcpu_run() (or maybe even
__vcpu_run()) handle UCALL_ABORT. The the bajillion REPORT_GUEST_ASSERT() calls
can be removed, as can UCALL_UNHANDLED and assert_on_unhandled_exception() since
they can and should use a normal GUEST_ASSERT() now that guest code can provide
the formating, and library code will ensure the assert is reported.
For this series, just ignore the GUEST_ASSERT() wonkiness. If someone develops
a test that uses udelay(), doesn't handle ucalls, _and_ runs on funky hardware,
then so be it, they can come yell at me :-)
And I'll work on a series to handle UCALL_ABORT in _vcpu_run() (and poke around
a bit more to see if there's other low hanging cleanup fruit).
next prev parent reply other threads:[~2024-06-12 1:15 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
2024-06-11 23:07 ` Reinette Chatre
2024-06-12 1:15 ` Sean Christopherson [this message]
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=Zmj2nVhtVoGflaiG@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