From: Cornelia Huck <cohuck@redhat.com>
To: Eric Auger <eauger@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Gavin Shan <gshan@redhat.com>
Subject: Re: [PATCH v4 2/2] qtests/arm: add some mte tests
Date: Thu, 26 Jan 2023 11:57:50 +0100 [thread overview]
Message-ID: <87a625y34h.fsf@redhat.com> (raw)
In-Reply-To: <be81e9e3-1669-4627-562e-30ab0a98c8fc@redhat.com>
On Mon, Jan 23 2023, Eric Auger <eauger@redhat.com> wrote:
> Hi Connie,
> On 1/11/23 17:13, Cornelia Huck wrote:
>> Acked-by: Thomas Huth <thuth@redhat.com>
>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> Maybe add some extra information about what tests are run. Also you
> could add an example of test invocation so that any people interested in
> can easily run those new tests?
Hm, it's just a part of the normal, standard qtests -- not sure what I
should add there?
>
>> ---
>> tests/qtest/arm-cpu-features.c | 76 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 76 insertions(+)
(...)
>> +static void mte_tests_default(QTestState *qts, const char *cpu_type)
>> +{
>> + assert_has_feature(qts, cpu_type, "mte");
>> +
>> + /*
>> + * Without tag memory, mte will be off under tcg.
>> + * Explicitly enabling it yields an error.
>> + */
>> + assert_has_feature(qts, cpu_type, "mte");
> called twice
Ok, that's probably some kind of rebase artifact.
>> +
>> + assert_set_feature_str(qts, "max", "mte", "off", "{ 'mte': 'off' }");
>> + assert_error(qts, cpu_type, "mte=on requires tag memory",
>> + "{ 'mte': 'on' }");
> nit. with pauth_tests_default form: cannot enable mte without tag memory
Not sure what you mean here?
>> +}
>> +
>> static void test_query_cpu_model_expansion(const void *data)
>> {
>> QTestState *qts;
>> @@ -473,6 +539,7 @@ static void test_query_cpu_model_expansion(const void *data)
>>
>> sve_tests_default(qts, "max");
>> pauth_tests_default(qts, "max");
>> + mte_tests_default(qts, "max");
>>
>> /* Test that features that depend on KVM generate errors without. */
>> assert_error(qts, "max",
>> @@ -516,6 +583,13 @@ static void test_query_cpu_model_expansion_kvm(const void *data)
>> assert_set_feature(qts, "host", "pmu", false);
>> assert_set_feature(qts, "host", "pmu", true);
>>
>> + /*
>> + * Unfortunately, there's no easy way to test whether this instance
>> + * of KVM supports MTE. So we can only assert that the feature
>> + * is present, but not whether it can be toggled.
>> + */
>> + assert_has_feature(qts, "host", "mte");
> why isn't it possible to implement something like
> kvm_supports_steal_time = resp_get_feature(resp, "kvm-steal-time");
> Could you elaborate?
I really should have written that down in detail, but I _think_ that's
because of OnOffAuto... if the prop is not set explicitly, we don't know
what is supported. Unless someone has an idea how to work around that?
prev parent reply other threads:[~2023-01-26 10:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 16:13 [PATCH v4 0/2] arm: enable MTE for QEMU + kvm Cornelia Huck
2023-01-11 16:13 ` [PATCH v4 1/2] arm/kvm: add support for MTE Cornelia Huck
2023-01-17 16:16 ` Peter Maydell
2023-01-17 16:50 ` Dr. David Alan Gilbert
2023-01-17 16:59 ` Cornelia Huck
2023-01-17 17:11 ` Dr. David Alan Gilbert
2023-01-17 17:01 ` Peter Maydell
2023-01-17 17:53 ` Dr. David Alan Gilbert
2023-01-17 16:52 ` Cornelia Huck
2023-01-17 19:37 ` Richard Henderson
2023-01-18 17:37 ` Cornelia Huck
2023-01-23 13:50 ` Eric Auger
2023-01-26 11:47 ` Cornelia Huck
2023-01-26 12:15 ` Cornelia Huck
2023-01-11 16:13 ` [PATCH v4 2/2] qtests/arm: add some mte tests Cornelia Huck
2023-01-17 7:21 ` Philippe Mathieu-Daudé
2023-01-23 14:29 ` Eric Auger
2023-01-26 10:57 ` Cornelia Huck [this message]
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=87a625y34h.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eauger@redhat.com \
--cc=gshan@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=thuth@redhat.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).