From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: qemu-s390x@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, Matthew Rosato <mjrosato@linux.ibm.com>
Subject: Re: [PATCH v2] vfio-ccw: Permit missing IRQs
Date: Fri, 23 Apr 2021 13:42:52 +0200 [thread overview]
Message-ID: <20210423134252.264059e5.cohuck@redhat.com> (raw)
In-Reply-To: <20210421152053.2379873-1-farman@linux.ibm.com>
On Wed, 21 Apr 2021 17:20:53 +0200
Eric Farman <farman@linux.ibm.com> wrote:
> Commit 690e29b91102 ("vfio-ccw: Refactor ccw irq handler") changed
> one of the checks for the IRQ notifier registration from saying
> "the host needs to recognize the only IRQ that exists" to saying
> "the host needs to recognize ANY IRQ that exists."
>
> And this worked fine, because the subsequent change to support the
> CRW IRQ notifier doesn't get into this code when running on an older
> kernel, thanks to a guard by a capability region. The later addition
> of the REQ(uest) IRQ by commit b2f96f9e4f5f ("vfio-ccw: Connect the
> device request notifier") broke this assumption because there is no
> matching capability region. Thus, running new QEMU on an older
> kernel fails with:
>
> vfio: unexpected number of irqs 2
>
> Let's adapt the message here so that there's a better clue of what
> IRQ is missing.
>
> Furthermore, let's make the REQ(uest) IRQ not fail when attempting
> to register it, to permit running vfio-ccw on a newer QEMU with an
> older kernel.
>
> Fixes: b2f96f9e4f5f ("vfio-ccw: Connect the device request notifier")
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>
> Notes:
> v1->v2:
> - Keep existing "invalid number of IRQs" message with adapted text [CH]
> - Move the "is this an error" test to the registration of the IRQ in
> question, rather than making it allowable for any IRQ mismatch [CH]
> - Drop Fixes tag for initial commit [EF]
>
> v1: https://lore.kernel.org/qemu-devel/20210419184906.2847283-1-farman@linux.ibm.com/
>
> hw/vfio/ccw.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
> index b2df708e4b..400bc07fe2 100644
> --- a/hw/vfio/ccw.c
> +++ b/hw/vfio/ccw.c
> @@ -412,8 +412,8 @@ static void vfio_ccw_register_irq_notifier(VFIOCCWDevice *vcdev,
> }
>
> if (vdev->num_irqs < irq + 1) {
> - error_setg(errp, "vfio: unexpected number of irqs %u",
> - vdev->num_irqs);
> + error_setg(errp, "vfio: IRQ %u not available (number of irqs %u)",
> + irq, vdev->num_irqs);
> return;
> }
>
> @@ -696,13 +696,15 @@ static void vfio_ccw_realize(DeviceState *dev, Error **errp)
>
> vfio_ccw_register_irq_notifier(vcdev, VFIO_CCW_REQ_IRQ_INDEX, &err);
> if (err) {
> - goto out_req_notifier_err;
> + /*
> + * Report this error, but do not make it a failing condition.
> + * Lack of this IRQ in the host does not prevent normal operation.
> + */
> + error_report_err(err);
> }
>
> return;
>
> -out_req_notifier_err:
> - vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_CRW_IRQ_INDEX);
> out_crw_notifier_err:
> vfio_ccw_unregister_irq_notifier(vcdev, VFIO_CCW_IO_IRQ_INDEX);
> out_io_notifier_err:
Patch looks good to me, but now I'm wondering: Is calling
vfio_ccw_unregister_irq_notifier() for an unregistered irq actually
safe? I think it is (our notifiers are always present, and we should
handle any ioctl failure gracefully), but worth a second look. In fact,
we already unregister the crw irq unconditionally, so we would likely
already have seen any problems for that one, so I assume all is good.
next prev parent reply other threads:[~2021-04-23 11:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 15:20 [PATCH v2] vfio-ccw: Permit missing IRQs Eric Farman
2021-04-23 11:42 ` Cornelia Huck [this message]
2021-04-23 13:22 ` Matthew Rosato
2021-04-23 16:24 ` Eric Farman
2021-04-26 13:07 ` Cornelia Huck
2021-04-26 13:07 ` Cornelia Huck
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=20210423134252.264059e5.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=farman@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/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.