From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: kvm@vger.kernel.org, thuth@redhat.com, borntraeger@de.ibm.com,
david@redhat.com, linux-s390@vger.kernel.org
Subject: Re: [PATCH v9 6/6] selftests: KVM: testing the local IRQs resets
Date: Thu, 30 Jan 2020 17:27:57 +0100 [thread overview]
Message-ID: <20200130172757.09b1bbed.cohuck@redhat.com> (raw)
In-Reply-To: <20200130123434.68129-7-frankja@linux.ibm.com>
On Thu, 30 Jan 2020 07:34:34 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> From: Pierre Morel <pmorel@linux.ibm.com>
>
> Local IRQs are reset by a normal cpu reset. The initial cpu reset and
> the clear cpu reset, as superset of the normal reset, both clear the
> IRQs too.
>
> Let's inject an interrupt to a vCPU before calling a reset and see if
> it is gone after the reset.
>
> We choose to inject only an emergency interrupt at this point and can
> extend the test to other types of IRQs later.
>
> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>[minor fixups]
> ---
> tools/testing/selftests/kvm/s390x/resets.c | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/tools/testing/selftests/kvm/s390x/resets.c b/tools/testing/selftests/kvm/s390x/resets.c
> index 4e173517f909..8a2507930e7d 100644
> --- a/tools/testing/selftests/kvm/s390x/resets.c
> +++ b/tools/testing/selftests/kvm/s390x/resets.c
> @@ -14,6 +14,9 @@
> #include "kvm_util.h"
>
> #define VCPU_ID 3
> +#define LOCAL_IRQS 32
The choice of 32 here is still a bit unclear (although not a problem).
> +
> +struct kvm_s390_irq buf[VCPU_ID + LOCAL_IRQS];
>
> struct kvm_vm *vm;
> struct kvm_run *run;
> @@ -53,6 +56,27 @@ static void test_one_reg(uint64_t id, uint64_t value)
> TEST_ASSERT(eval_reg == value, "value == %s", value);
> }
>
> +static void assert_noirq(void)
> +{
> + struct kvm_s390_irq_state irq_state;
> + int irqs;
> +
> + if (!(kvm_check_cap(KVM_CAP_S390_INJECT_IRQ) &&
> + kvm_check_cap(KVM_CAP_S390_IRQ_STATE)))
> + return;
I think you should drop the capability check here as well.
> +
> + irq_state.len = sizeof(buf);
> + irq_state.buf = (unsigned long)buf;
> + irqs = _vcpu_ioctl(vm, VCPU_ID, KVM_S390_GET_IRQ_STATE, &irq_state);
> + /*
> + * irqs contains the number of retrieved interrupts, apart from the
> + * emergency call that should be cleared by the resets, there should be
> + * none.
What about the updated comment? :)
> + */
> + TEST_ASSERT(irqs >= 0, "Could not fetch IRQs: errno %d\n", errno);
> + TEST_ASSERT(!irqs, "IRQ pending");
> +}
> +
> static void assert_clear(void)
> {
> struct kvm_sregs sregs;
Else, looks sane to me.
prev parent reply other threads:[~2020-01-30 16:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 12:34 [PATCH v9 0/6] KVM: s390: Add new reset vcpu API Janosch Frank
2020-01-30 12:34 ` [PATCH v9 1/6] KVM: s390: do not clobber registers during guest reset/store status Janosch Frank
2020-01-30 12:39 ` David Hildenbrand
2020-01-30 13:00 ` Cornelia Huck
2020-01-30 13:02 ` Christian Borntraeger
2020-01-30 12:34 ` [PATCH v9 2/6] KVM: s390: Cleanup initial cpu reset Janosch Frank
2020-01-30 13:20 ` Thomas Huth
2020-01-30 12:34 ` [PATCH v9 3/6] KVM: s390: Add new reset vcpu API Janosch Frank
2020-01-30 12:49 ` Janosch Frank
2020-01-30 12:55 ` [PATCH v9] " Janosch Frank
2020-01-30 12:59 ` Christian Borntraeger
2020-01-30 13:02 ` Janosch Frank
2020-01-30 13:01 ` Cornelia Huck
2020-01-30 12:53 ` [PATCH v9 3/6] " Christian Borntraeger
2020-01-30 12:34 ` [PATCH v9 4/6] selftests: KVM: Add fpu and one reg set/get library functions Janosch Frank
2020-01-30 13:03 ` Cornelia Huck
2020-01-30 12:34 ` [PATCH v9 5/6] selftests: KVM: s390x: Add reset tests Janosch Frank
2020-01-30 13:25 ` Thomas Huth
2020-01-30 16:22 ` Cornelia Huck
2020-01-30 12:34 ` [PATCH v9 6/6] selftests: KVM: testing the local IRQs resets Janosch Frank
2020-01-30 16:27 ` 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=20200130172757.09b1bbed.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--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