From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Farhan Ali <alifm@linux.ibm.com>,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Cc: farman@linux.ibm.com, cohuck@redhat.com, alex@shazbot.org,
clg@redhat.com
Subject: Re: [PATCH v6 1/2] s390x/pci: Add PCI error handling for vfio pci devices
Date: Wed, 30 Sep 2026 12:30:27 -0400 [thread overview]
Message-ID: <2ee98743-546b-4726-904a-6fe828dbb175@linux.ibm.com> (raw)
In-Reply-To: <20260922171756.920-2-alifm@linux.ibm.com>
> +static int s390_pci_get_feature_err(VFIOPCIDevice *vfio_pci,
> + PciCcdfErr *ccdf,
> + uint32_t ccdf_err_length,
> + Error **errp)
> +{
> + ERRP_GUARD();
> + int ret;
> + size_t total_size;
> + struct vfio_device_feature_zpci_err *err;
> + g_autofree void *buf = NULL;
> + g_autofree struct vfio_device_feature *feature = NULL;
> +
> + total_size = sizeof(*feature) + sizeof(*err);
> + feature = g_malloc(total_size);
> + feature->argsz = total_size;
> + feature->flags = VFIO_DEVICE_FEATURE_GET | VFIO_DEVICE_FEATURE_ZPCI_ERROR;
> +
> + buf = g_malloc(ccdf_err_length);
> + err = (void *)feature->data;
> + err->data = (uint64_t)buf;
> + ret = vfio_device_get_feature(&vfio_pci->vbasedev, feature);
> +
> + if (ret) {
> + error_setg(errp, "Failed feature get VFIO_DEVICE_FEATURE_ZPCI_ERROR"
> + " (rc=%d)", ret);
I see this was changed from last version, but doesn't this fall under
'avoid useless error object creation and destruction' described in
qapi/error.h for the -ENOMSG return value?
We create it here only to explicitly destroy it from the caller.
Can we instead switch to the negative/non-negative return structure with
something like...
<0: error as defined (so we set errp)
0-N: number of errors to process (and we do not set errp)
For the non-negative case we can realistically only have 0 (-ENOMSG maps
to this) or 1 (the feature found something - it is reporting 1 error to
handle).
> + return ret;
> + }
> +
> + memcpy(ccdf, (PciCcdfErr *) err->data, ccdf_err_length);
You already had err->data in void *buf, can we just
memcpy(ccdf, buf, ccdf_err_length);
> +
> + return 0;
> +}
> +
> +static void s390_pci_err_handler(void *opaque)
> +{
> + VFIOPCIDevice *vfio_pci;
> + S390PCIBusDevice *pbdev;
> + Error *local_err = NULL;
> + PciCcdfErr ccdf;
> + int ret = 0;
> +
> + vfio_pci = opaque;
> + if (!event_notifier_test_and_clear(&vfio_pci->err_notifier)) {
> + return;
> + }
Another one I should have commented on during v5... You're right about
the recent patch and Z support, but what if the patch is missing on the
host kernel?
I'm fine with the feature not working with AER is off rather than doing
our own setup, but don't we need to avoid referencing this in that case
and ideally give some log message?
> +
> + pbdev = s390_pci_find_dev_by_target(s390_get_phb(),
> + DEVICE(&vfio_pci->parent_obj)->id);
> +
We can get the pci device from the vfio-pci device, so would it work to
just do this?
s390_pci_find_dev_by_pci(s390_get_phb(), PCI_DEVICE(vfio_pci));
Then we cut out the strcmps
Thanks,
Matt
next prev parent reply other threads:[~2026-09-30 16:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 17:17 [PATCH v6 0/2] Error recovery for zPCI passthrough devices Farhan Ali
2026-09-22 17:17 ` [PATCH v6 1/2] s390x/pci: Add PCI error handling for vfio pci devices Farhan Ali
2026-09-30 16:30 ` Matthew Rosato [this message]
2026-09-30 17:46 ` Farhan Ali
2026-10-01 15:43 ` Matthew Rosato
2026-09-22 17:17 ` [PATCH v6 2/2] s390x/pci: Reset a device in error state Farhan Ali
2026-09-30 15:32 ` Matthew Rosato
2026-09-30 18:25 ` Farhan Ali
2026-09-30 21:50 ` Matthew Rosato
2026-09-30 21:54 ` Matthew Rosato
2026-09-29 18:03 ` [PATCH v6 0/2] Error recovery for zPCI passthrough devices Farhan Ali
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=2ee98743-546b-4726-904a-6fe828dbb175@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=alex@shazbot.org \
--cc=alifm@linux.ibm.com \
--cc=clg@redhat.com \
--cc=cohuck@redhat.com \
--cc=farman@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.