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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.