[{"id":3676956,"web_url":"http://patchwork.ozlabs.org/comment/3676956/","msgid":"<20260413165758.0f87312b@shazbot.org>","list_archive_url":null,"date":"2026-04-13T22:57:58","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":91887,"url":"http://patchwork.ozlabs.org/api/people/91887/","name":"Alex Williamson","email":"alex@shazbot.org"},"content":"On Mon, 13 Apr 2026 14:06:06 -0700\nFarhan Ali wrote:\n\n> For zPCI devices, we have platform specific error information. The platform\n> firmware provides this error information to the operating system in an\n> architecture specific mechanism. To enable recovery from userspace for\n> these devices, we want to expose this error information to userspace. Add a\n> new device feature to expose this information.\n> \n> Reviewed-by: Matthew Rosato \n> Signed-off-by: Farhan Ali \n> ---\n> arch/s390/include/asm/pci.h | 3 +++\n> arch/s390/pci/pci_event.c | 19 +++++++++++++++++++\n> drivers/vfio/pci/vfio_pci_core.c | 2 ++\n> drivers/vfio/pci/vfio_pci_priv.h | 9 +++++++++\n> drivers/vfio/pci/vfio_pci_zdev.c | 31 +++++++++++++++++++++++++++++++\n> include/uapi/linux/vfio.h | 20 ++++++++++++++++++++\n> 6 files changed, 84 insertions(+)\n> \n> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h\n> index 9a6a4eb9d7c1..9c8ee97d7e8a 100644\n> --- a/arch/s390/include/asm/pci.h\n> +++ b/arch/s390/include/asm/pci.h\n> @@ -360,6 +360,9 @@ int zpci_clear_error_state(struct zpci_dev *zdev);\n> int zpci_reset_load_store_blocked(struct zpci_dev *zdev);\n> void zpci_start_mediated_recovery(struct zpci_dev *zdev);\n> void zpci_stop_mediated_recovery(struct zpci_dev *zdev);\n> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n> +\t\t\t\t int *count);\n> \n> #ifdef CONFIG_NUMA\n> \n> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c\n> index c279a9f50a64..c8714d4a32fa 100644\n> --- a/arch/s390/pci/pci_event.c\n> +++ b/arch/s390/pci/pci_event.c\n> @@ -74,6 +74,25 @@ static void zpci_store_pci_error(struct pci_dev *pdev,\n> \tzdev->pending_errs.count++;\n> }\n> \n> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n> +\t\t\t\t int *count)\n> +{\n> +\tint head = 0;\n\nUnnecessary. Should also be a blank line between variable declaration\nand code.\n\n> +\t*count = 0;\n\nBut why do we zero this and not ccdf?\n\n> +\n> +\tguard(mutex)(&zdev->pending_errs_lock);\n> +\tif (zdev->pending_errs.count) {\n> +\t\thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n> +\t\tmemcpy(ccdf, &zdev->pending_errs.err[head],\n> +\t\t sizeof(struct zpci_ccdf_err));\n> +\t\tzdev->pending_errs.head++;\n> +\t\tzdev->pending_errs.count--;\n> +\t\t*count = zdev->pending_errs.count;\n> +\t}\n> +}\n\nYou've describe in the uAPI now how pec = 0 means no error, but why not\nremove that ambiguity altogether and return -ENOMSG in that case. We\ncould start here and pass it through:\n\n{\n\tint head;\n\n\tguard(mutex)(&zdev->pending_errs_lock);\n\n\tif (!zdev->pending_errs.count)\n\t\treturn -ENOMSG;\n\n\thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n\tmemcpy(ccdf, &zdev->pending_errs.err[head],\n\t sizeof(struct zpci_ccdf_err));\n\tzdev->pending_errs.head++;\n\tzdev->pending_errs.count--;\n\t*count = zdev->pending_errs.count;\n\n\treturn 0;\n}\n\n> +EXPORT_SYMBOL_GPL(zpci_get_pending_error_and_count);\n> +\n> void zpci_start_mediated_recovery(struct zpci_dev *zdev)\n> {\n> \tguard(mutex)(&zdev->pending_errs_lock);\n> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n> index ad52abc46c04..5403730786a1 100644\n> --- a/drivers/vfio/pci/vfio_pci_core.c\n> +++ b/drivers/vfio/pci/vfio_pci_core.c\n> @@ -1534,6 +1534,8 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,\n> \t\treturn vfio_pci_core_feature_token(vdev, flags, arg, argsz);\n> \tcase VFIO_DEVICE_FEATURE_DMA_BUF:\n> \t\treturn vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);\n> +\tcase VFIO_DEVICE_FEATURE_ZPCI_ERROR:\n> +\t\treturn vfio_pci_zdev_feature_err(device, flags, arg, argsz);\n> \tdefault:\n> \t\treturn -ENOTTY;\n> \t}\n> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h\n> index fca9d0dfac90..4e7162234a2e 100644\n> --- a/drivers/vfio/pci/vfio_pci_priv.h\n> +++ b/drivers/vfio/pci/vfio_pci_priv.h\n> @@ -93,6 +93,8 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> \t\t\t\tstruct vfio_info_cap *caps);\n> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);\n> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);\n> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n> +\t\t\t void __user *arg, size_t argsz);\n> #else\n> static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> \t\t\t\t\t struct vfio_info_cap *caps)\n> @@ -107,6 +109,13 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n> \n> static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)\n> {}\n> +\n> +static inline int vfio_pci_zdev_feature_err(struct vfio_device *device,\n> +\t\t\t\t\t u32 flags, void __user *arg,\n> +\t\t\t\t\t size_t argsz)\n> +{\n> +\treturn -ENOTTY;\n> +}\n> #endif\n> \n> static inline bool vfio_pci_is_vga(struct pci_dev *pdev)\n> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c\n> index 0658095ac5b1..ee1647f0ffe6 100644\n> --- a/drivers/vfio/pci/vfio_pci_zdev.c\n> +++ b/drivers/vfio/pci/vfio_pci_zdev.c\n> @@ -141,6 +141,37 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> \treturn ret;\n> }\n> \n> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n> +\t\t\t void __user *arg, size_t argsz)\n> +{\n> +\tstruct vfio_device_feature_zpci_err err = {};\n> +\tstruct vfio_pci_core_device *vdev;\n> +\tstruct zpci_ccdf_err ccdf = {};\n> +\tstruct zpci_dev *zdev;\n> +\tint pending_errors = 0;\n> +\tint ret;\n> +\n> +\tvdev = container_of(device, struct vfio_pci_core_device, vdev);\n> +\tzdev = to_zpci(vdev->pdev);\n> +\tif (!zdev)\n> +\t\treturn -ENODEV;\n> +\n> +\tret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,\n> +\t\t\t\t sizeof(err));\n> +\tif (ret != 1)\n> +\t\treturn ret;\n> +\n> +\tzpci_get_pending_error_and_count(zdev, &ccdf, &pending_errors);\n> +\n> +\terr.version = 1;\n> +\terr.pec = ccdf.pec;\n> +\terr.pending_errors = pending_errors;\n> +\tif (copy_to_user(arg, &err, sizeof(err)))\n> +\t\treturn -EFAULT;\n> +\n> +\treturn 0;\n> +}\n> +\n> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n> {\n> \tstruct zpci_dev *zdev = to_zpci(vdev->pdev);\n> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> index 5de618a3a5ee..2980ca39dd38 100644\n> --- a/include/uapi/linux/vfio.h\n> +++ b/include/uapi/linux/vfio.h\n> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n> */\n> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n> \n> +/**\n> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n> + * involves platform firmware and notification to operating system is done\n> + * by architecture specific mechanism. Exposing this information to\n> + * userspace allows it to take appropriate actions to handle an\n> + * error on the device. The pending_errors provide any additional errors\n> + * pending for the device, and userspace should read until zero. A value of\n> + * 0 for pending_errors and pec would indicate no pending errors that need\n> + * to be handled.\n> + */\n> +\n> +struct vfio_device_feature_zpci_err {\n> +\t__u8 version;\n> +\t__u8 pending_errors;\n> +\t__u16 pec;\n> +};\n\nI assume .version is for compatibility, but we don't define a strategy\nfor using it or specify what the version should be for this table. It\ndoesn't seem like there's actually an value-add to having it.\n\nI'm also not clear why we need to report .pending_errors. It mostly\nseems like another ambiguous feature of this API. The value seems\nvolatile and the suggestion is to read until zero, so why provide the\nvalue at all, the user can just read until -ENOMSG.\n\nAt that point, maybe we don't even need a return structure at all,\nreturn small positive values for pec or -errno. The internal API could\nmatch, avoiding the pass by address parameters. Thanks,\n\nAlex\n\n\n> +\n> +#define VFIO_DEVICE_FEATURE_ZPCI_ERROR 13\n> +\n> /* -------- API for Type1 VFIO IOMMU -------- */\n> \n> /**","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=shazbot.org header.i=@shazbot.org header.a=rsa-sha256\n header.s=fm1 header.b=sFWUgu7o;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=Z110tKhh;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52457-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=\"sFWUgu7o\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"Z110tKhh\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=103.168.172.149","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=shazbot.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvjZX4Wfdz1yD4\n\tfor ; Tue, 14 Apr 2026 09:01:24 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id CF32A301AD22\n\tfor ; Mon, 13 Apr 2026 22:58:05 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 0A74139D6F2;\n\tMon, 13 Apr 2026 22:58:05 +0000 (UTC)","from fout-a6-smtp.messagingengine.com\n (fout-a6-smtp.messagingengine.com [103.168.172.149])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id BDE4D344030;\n\tMon, 13 Apr 2026 22:58:02 +0000 (UTC)","from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42])\n\tby mailfout.phl.internal (Postfix) with ESMTP id 1786CEC049A;\n\tMon, 13 Apr 2026 18:58:02 -0400 (EDT)","from phl-frontend-04 ([10.202.2.163])\n by phl-compute-02.internal (MEProxy); Mon, 13 Apr 2026 18:58:02 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Mon,\n 13 Apr 2026 18:58:00 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776121084; cv=none;\n b=vDRZtweJrolZzstWMTFp0f3vVKDchCpLFbhJOUqfhPMzh9yAYTI7sKEeWdl+32DkZQaaEl01xuyQaaS1Ua1jG6HtkpsCsw22Q6nU3WdTfaGmI0zfcLqVshsLPhj+aI3Kq0yOjMQCj2gsb9zHOTgaH1ZtrQgbQ28NZKFgrSxzYSM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776121084; c=relaxed/simple;\n\tbh=T65vjW3ln7RnLzou1KlmiqfAkTKogbtofHn/WGoV0OU=;\n\th=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:\n\t MIME-Version:Content-Type;\n b=A6W0WwzK7rs/2eT8gk6ftIAHH8LY3SHZwX6Rql7qz/0QcNQgCfcrPU8582fWoJoqqCKqoctdoGcbE7hSEAMNVU4A3batmjErQnP/Y1rhXk7PYWbw5Ovr1qSEnCg2t4imykYLC/qNw31p8MuYNkGaNmVk0yTz5kJJj0O+eCC5LgY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org;\n spf=pass smtp.mailfrom=shazbot.org;\n dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=sFWUgu7o;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=Z110tKhh; arc=none smtp.client-ip=103.168.172.149","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=shazbot.org; h=\n\tcc:cc:content-transfer-encoding:content-type:content-type:date\n\t:date:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to; s=fm1; t=1776121082;\n\t x=1776207482; bh=L53ZKnsNwzHCkMZLz5adh9nwFhC/OP8f3LxsohqLMOM=; b=\n\tsFWUgu7ohDodVom3kand+FiIPaYefUeu2gkZtUT0yyzPLLBQmFuJod/ydcl50gK8\n\tDS88F9JlFin1B4R0fY0HA5SMlEO0ajKvndw4DwqaGYPx7EscTVDiafNmN2erYpLW\n\tnYhIHf9rpXmXV5fQHFht7bhQjcCPg3Y6y0P2rfg7WaFtXjntt5LiUbeJQSDiqJVF\n\tWM9AJoIM6rUML3FeWuRVmPAAIjdDYqFFlfLaB3vOIp7xK9xWCE1+h27uXwlV2/iE\n\t5WCVGkyw0vOTjvqARvpYx4/LgAqiMiQtOJk/FeRuZED9j5LHvzCxN+OFboSz1cAJ\n\tlWaUAweApMKUHEbP75vChA==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:cc:content-transfer-encoding\n\t:content-type:content-type:date:date:feedback-id:feedback-id\n\t:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to:x-me-proxy\n\t:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1776121082; x=\n\t1776207482; bh=L53ZKnsNwzHCkMZLz5adh9nwFhC/OP8f3LxsohqLMOM=; b=Z\n\t110tKhhhWlTRCYa26chwCLPZJs+Sf3fTpW4fLqAQeSITRLw1GVLP8qMoK12amXo5\n\tKn3PbFYNSGU5d/m8S7IcaZADCzRyKNVh7CMLea3wPCtRohBDdZCk3NNm8UVc/SVe\n\toBshLuYRIQENLQUFL9Mzoq/YjrfvG15pH/3bjr4RXYo5/5DYkxzzkiBjI4Drb6e8\n\tLKqjdJzHDu+vEVBqxFjPukpO/V6ORB+WvRphZU/I6hQC1y99mhF30gwZQaoppijO\n\t4AwkbsgwD6+QgTKTml2gd+2NRTNcQF0H+GFMiIuP/xtDiIhZA2Uv2GMNlbOS4waK\n\tdA/IG3hF06Re/HCEp9Snw=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdefleehudcutefuodetggdotefrod\n ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n ihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkjghfofggtgfgsehtjeertd\n ertddvnecuhfhrohhmpeetlhgvgicuhghilhhlihgrmhhsohhnuceorghlvgigsehshhgr\n iigsohhtrdhorhhgqeenucggtffrrghtthgvrhhnpedvkeefjeekvdduhfduhfetkedugf\n duieettedvueekvdehtedvkefgudegveeuueenucevlhhushhtvghrufhiiigvpedtnecu\n rfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgiesshhhrgiisghothdrohhrghdpnhgspg\n hrtghpthhtohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrlhhifhhm\n sehlihhnuhigrdhisghmrdgtohhmpdhrtghpthhtoheplhhinhhugidqshefledtsehvgh\n gvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehv\n ghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphgtihesvhhgvg\n hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehhvghlghgrrghssehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehluhhkrghsseifuhhnnhgvrhdruggvpdhrtghpthhtoheptg\n hlghesrhgvughhrghtrdgtohhmpdhrtghpthhtohepkhgsuhhstghhsehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehstghhnhgvlhhlvgeslhhinhhugidrihgsmhdrtghomh","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"i03f14258:Fastmail","Date":"Mon, 13 Apr 2026 16:57:58 -0600","From":"Alex Williamson ","To":"Farhan Ali ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com, alex@shazbot.org","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","Message-ID":"<20260413165758.0f87312b@shazbot.org>","In-Reply-To":"<20260413210608.2912-6-alifm@linux.ibm.com>","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n\t<20260413210608.2912-6-alifm@linux.ibm.com>","X-Mailer":"Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":3676976,"web_url":"http://patchwork.ozlabs.org/comment/3676976/","msgid":"","list_archive_url":null,"date":"2026-04-13T23:40:49","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":73785,"url":"http://patchwork.ozlabs.org/api/people/73785/","name":"Farhan Ali","email":"alifm@linux.ibm.com"},"content":"On 4/13/2026 3:57 PM, Alex Williamson wrote:\n> On Mon, 13 Apr 2026 14:06:06 -0700\n> Farhan Ali wrote:\n>\n>> For zPCI devices, we have platform specific error information. The platform\n>> firmware provides this error information to the operating system in an\n>> architecture specific mechanism. To enable recovery from userspace for\n>> these devices, we want to expose this error information to userspace. Add a\n>> new device feature to expose this information.\n>>\n>> Reviewed-by: Matthew Rosato \n>> Signed-off-by: Farhan Ali \n>> ---\n>> arch/s390/include/asm/pci.h | 3 +++\n>> arch/s390/pci/pci_event.c | 19 +++++++++++++++++++\n>> drivers/vfio/pci/vfio_pci_core.c | 2 ++\n>> drivers/vfio/pci/vfio_pci_priv.h | 9 +++++++++\n>> drivers/vfio/pci/vfio_pci_zdev.c | 31 +++++++++++++++++++++++++++++++\n>> include/uapi/linux/vfio.h | 20 ++++++++++++++++++++\n>> 6 files changed, 84 insertions(+)\n>>\n>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h\n>> index 9a6a4eb9d7c1..9c8ee97d7e8a 100644\n>> --- a/arch/s390/include/asm/pci.h\n>> +++ b/arch/s390/include/asm/pci.h\n>> @@ -360,6 +360,9 @@ int zpci_clear_error_state(struct zpci_dev *zdev);\n>> int zpci_reset_load_store_blocked(struct zpci_dev *zdev);\n>> void zpci_start_mediated_recovery(struct zpci_dev *zdev);\n>> void zpci_stop_mediated_recovery(struct zpci_dev *zdev);\n>> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n>> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n>> +\t\t\t\t int *count);\n>> \n>> #ifdef CONFIG_NUMA\n>> \n>> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c\n>> index c279a9f50a64..c8714d4a32fa 100644\n>> --- a/arch/s390/pci/pci_event.c\n>> +++ b/arch/s390/pci/pci_event.c\n>> @@ -74,6 +74,25 @@ static void zpci_store_pci_error(struct pci_dev *pdev,\n>> \tzdev->pending_errs.count++;\n>> }\n>> \n>> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n>> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n>> +\t\t\t\t int *count)\n>> +{\n>> +\tint head = 0;\n> Unnecessary. Should also be a blank line between variable declaration\n> and code.\n>\n>> +\t*count = 0;\n> But why do we zero this and not ccdf?\n\nI had thought of memsetting ccdf to 0, but the only caller right already \ninitializes to 0. So didn't think it was needed.\n\n\n>\n>> +\n>> +\tguard(mutex)(&zdev->pending_errs_lock);\n>> +\tif (zdev->pending_errs.count) {\n>> +\t\thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n>> +\t\tmemcpy(ccdf, &zdev->pending_errs.err[head],\n>> +\t\t sizeof(struct zpci_ccdf_err));\n>> +\t\tzdev->pending_errs.head++;\n>> +\t\tzdev->pending_errs.count--;\n>> +\t\t*count = zdev->pending_errs.count;\n>> +\t}\n>> +}\n> You've describe in the uAPI now how pec = 0 means no error, but why not\n> remove that ambiguity altogether and return -ENOMSG in that case. We\n> could start here and pass it through:\n>\n> {\n> \tint head;\n>\n> \tguard(mutex)(&zdev->pending_errs_lock);\n>\n> \tif (!zdev->pending_errs.count)\n> \t\treturn -ENOMSG;\n>\n> \thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n> \tmemcpy(ccdf, &zdev->pending_errs.err[head],\n> \t sizeof(struct zpci_ccdf_err));\n> \tzdev->pending_errs.head++;\n> \tzdev->pending_errs.count--;\n> \t*count = zdev->pending_errs.count;\n>\n> \treturn 0;\n> }\n\nI had thought of returning an error (ENOENT was what I was going with), \nbut perhaps I misunderstood your comment from v12 about specifying pec = \n0 and pending error = 0 as not being an error. My assumption was as this \nis not an error we shouldn't return an error to userspace.\n\n\n>> +EXPORT_SYMBOL_GPL(zpci_get_pending_error_and_count);\n>> +\n>> void zpci_start_mediated_recovery(struct zpci_dev *zdev)\n>> {\n>> \tguard(mutex)(&zdev->pending_errs_lock);\n>> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n>> index ad52abc46c04..5403730786a1 100644\n>> --- a/drivers/vfio/pci/vfio_pci_core.c\n>> +++ b/drivers/vfio/pci/vfio_pci_core.c\n>> @@ -1534,6 +1534,8 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,\n>> \t\treturn vfio_pci_core_feature_token(vdev, flags, arg, argsz);\n>> \tcase VFIO_DEVICE_FEATURE_DMA_BUF:\n>> \t\treturn vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);\n>> +\tcase VFIO_DEVICE_FEATURE_ZPCI_ERROR:\n>> +\t\treturn vfio_pci_zdev_feature_err(device, flags, arg, argsz);\n>> \tdefault:\n>> \t\treturn -ENOTTY;\n>> \t}\n>> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h\n>> index fca9d0dfac90..4e7162234a2e 100644\n>> --- a/drivers/vfio/pci/vfio_pci_priv.h\n>> +++ b/drivers/vfio/pci/vfio_pci_priv.h\n>> @@ -93,6 +93,8 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>> \t\t\t\tstruct vfio_info_cap *caps);\n>> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);\n>> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);\n>> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n>> +\t\t\t void __user *arg, size_t argsz);\n>> #else\n>> static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>> \t\t\t\t\t struct vfio_info_cap *caps)\n>> @@ -107,6 +109,13 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n>> \n>> static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)\n>> {}\n>> +\n>> +static inline int vfio_pci_zdev_feature_err(struct vfio_device *device,\n>> +\t\t\t\t\t u32 flags, void __user *arg,\n>> +\t\t\t\t\t size_t argsz)\n>> +{\n>> +\treturn -ENOTTY;\n>> +}\n>> #endif\n>> \n>> static inline bool vfio_pci_is_vga(struct pci_dev *pdev)\n>> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c\n>> index 0658095ac5b1..ee1647f0ffe6 100644\n>> --- a/drivers/vfio/pci/vfio_pci_zdev.c\n>> +++ b/drivers/vfio/pci/vfio_pci_zdev.c\n>> @@ -141,6 +141,37 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>> \treturn ret;\n>> }\n>> \n>> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n>> +\t\t\t void __user *arg, size_t argsz)\n>> +{\n>> +\tstruct vfio_device_feature_zpci_err err = {};\n>> +\tstruct vfio_pci_core_device *vdev;\n>> +\tstruct zpci_ccdf_err ccdf = {};\n>> +\tstruct zpci_dev *zdev;\n>> +\tint pending_errors = 0;\n>> +\tint ret;\n>> +\n>> +\tvdev = container_of(device, struct vfio_pci_core_device, vdev);\n>> +\tzdev = to_zpci(vdev->pdev);\n>> +\tif (!zdev)\n>> +\t\treturn -ENODEV;\n>> +\n>> +\tret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,\n>> +\t\t\t\t sizeof(err));\n>> +\tif (ret != 1)\n>> +\t\treturn ret;\n>> +\n>> +\tzpci_get_pending_error_and_count(zdev, &ccdf, &pending_errors);\n>> +\n>> +\terr.version = 1;\n>> +\terr.pec = ccdf.pec;\n>> +\terr.pending_errors = pending_errors;\n>> +\tif (copy_to_user(arg, &err, sizeof(err)))\n>> +\t\treturn -EFAULT;\n>> +\n>> +\treturn 0;\n>> +}\n>> +\n>> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n>> {\n>> \tstruct zpci_dev *zdev = to_zpci(vdev->pdev);\n>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n>> index 5de618a3a5ee..2980ca39dd38 100644\n>> --- a/include/uapi/linux/vfio.h\n>> +++ b/include/uapi/linux/vfio.h\n>> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n>> */\n>> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n>> \n>> +/**\n>> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n>> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n>> + * involves platform firmware and notification to operating system is done\n>> + * by architecture specific mechanism. Exposing this information to\n>> + * userspace allows it to take appropriate actions to handle an\n>> + * error on the device. The pending_errors provide any additional errors\n>> + * pending for the device, and userspace should read until zero. A value of\n>> + * 0 for pending_errors and pec would indicate no pending errors that need\n>> + * to be handled.\n>> + */\n>> +\n>> +struct vfio_device_feature_zpci_err {\n>> +\t__u8 version;\n>> +\t__u8 pending_errors;\n>> +\t__u16 pec;\n>> +};\n> I assume .version is for compatibility, but we don't define a strategy\n> for using it or specify what the version should be for this table. It\n> doesn't seem like there's actually an value-add to having it.\n\nIts possible we may need to extend this structure in the future if we \nwant to report more information to userspace. I at least want the \nflexibility to do so. We had some discussion around this [1] in an \nearlier version. I was trying to follow similar versioning pattern we \nhad around vfio-pci/zdev structures.\n\n[1] \nhttps://lore.kernel.org/all/88289f74-3d4f-4dd9-8f2a-8871d150fd50@linux.ibm.com/\n\n>\n> I'm also not clear why we need to report .pending_errors. It mostly\n> seems like another ambiguous feature of this API. The value seems\n> volatile and the suggestion is to read until zero, so why provide the\n> value at all, the user can just read until -ENOMSG.\n\nSince we don't explicitly return an error indicating there are no \navailable pci errors to handle, was why I added it. Is the preference to \njust return linux error code here?\n\nThanks\n\nFarhan\n\n>\n> At that point, maybe we don't even need a return structure at all,\n> return small positive values for pec or -errno. The internal API could\n> match, avoiding the pass by address parameters. Thanks,\n>\n> Alex\n>\n>\n>> +\n>> +#define VFIO_DEVICE_FEATURE_ZPCI_ERROR 13\n>> +\n>> /* -------- API for Type1 VFIO IOMMU -------- */\n>> \n>> /**","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=YfOZuesJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52458-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"YfOZuesJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.158.5","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvkSZ3mL5z1xtJ\n\tfor ; Tue, 14 Apr 2026 09:41:18 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 33955301169C\n\tfor ; Mon, 13 Apr 2026 23:41:02 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C057437B01A;\n\tMon, 13 Apr 2026 23:41:00 +0000 (UTC)","from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n [148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 27BCB35E949;\n\tMon, 13 Apr 2026 23:40:58 +0000 (UTC)","from pps.filterd (m0360072.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63DLIFHQ1804537;\n\tMon, 13 Apr 2026 23:40:53 GMT","from ppma21.wdc07v.mail.ibm.com\n (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89k0a80-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tMon, 13 Apr 2026 23:40:53 +0000 (GMT)","from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1])\n\tby ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63DM0IfU003514;\n\tMon, 13 Apr 2026 23:40:52 GMT","from smtprelay07.wdc07v.mail.ibm.com ([172.16.1.74])\n\tby ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4dg1mn789c-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tMon, 13 Apr 2026 23:40:52 +0000","from smtpav03.wdc07v.mail.ibm.com (smtpav03.wdc07v.mail.ibm.com\n [10.39.53.230])\n\tby smtprelay07.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63DNepcG26149574\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tMon, 13 Apr 2026 23:40:51 GMT","from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 6769A5805C;\n\tMon, 13 Apr 2026 23:40:51 +0000 (GMT)","from smtpav03.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 4B92558054;\n\tMon, 13 Apr 2026 23:40:50 +0000 (GMT)","from [9.61.242.98] (unknown [9.61.242.98])\n\tby smtpav03.wdc07v.mail.ibm.com (Postfix) with ESMTP;\n\tMon, 13 Apr 2026 23:40:50 +0000 (GMT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776123660; cv=none;\n b=R5/nVZdPa3KVXGNdmsao/BcMrYyBRnVW4aAo2xgkRVL1gvmCH6LYXoP3gMtKK7dcolXtZDbY5/Cq4Gl5cff5d5PUpVU0iQOawi6yWfWky08q0+6IDWemgM19YhglujW/n+6yQkyMfunTJPR3+aWTfFCKojaeRdc5vS9FvFDjmXU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776123660; c=relaxed/simple;\n\tbh=MAiEAcmw9bIasbQc42qB2Mu70OEKB/rRrgqlAtn/oPc=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=Z8nXebVaekMCEoPaJqtt7MMnb3Es2P+70r4VPwiZnaQg91FmFb6mTK4oM5QoijKMXvwL3WhEq+X8T4DkBXoFg1tLaRPOvFhw+i8jheXHnoorAjuF0pHxHq1AEWwKnDkXZpXd+JyOzhZ8U3VocZEV8fd4CmCdJcwD0qHEpOqWE08=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=YfOZuesJ; arc=none smtp.client-ip=148.163.158.5","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=pp1; bh=nRrPRH\n\tvAx0lYxy3y85QdUpSwvFTrFT9GLgDb39V+ryg=; b=YfOZuesJfiAsviHtCDEZsx\n\tdWQZfQ0Tk8ul5NS0i1HhKS5KgsvYmPhudJ4j/PiOk1FRZcALTknGcqOqfjDGOYf1\n\tXZ1yQXGSLjRnlmr8Oji4pUkcil32m3fYhgUMC+oYH6RSdqHbwNqZn4GMPQr9ziiW\n\tpZgqgb9QzjFN/6TllmDk6SbNp2CDyCbkmkb/CFQPuFfzbSmsaZDfYJSmfIaSxfZI\n\tXe0j8Bt5CMnkPC/rgfmZ4yj1Dbft88qey+t0vEovHzyBHu8n9qxA1yndGFxet2+a\n\t/vNSztpDpuVrgl/WnqmPDEQ9Q3YY4AhpVASgCu14MaEC8Q+zhASDg4QWHa8DqBCA\n\t==","Message-ID":"","Date":"Mon, 13 Apr 2026 16:40:49 -0700","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","To":"Alex Williamson ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n <20260413210608.2912-6-alifm@linux.ibm.com>\n <20260413165758.0f87312b@shazbot.org>","Content-Language":"en-US","From":"Farhan Ali ","In-Reply-To":"<20260413165758.0f87312b@shazbot.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","X-Proofpoint-GUID":"kB3pJ4wLEUyKh3m8mDOvvYKlW5_Xg91H","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDEzMDIyOSBTYWx0ZWRfX8BpfcXUdMbNr\n H20hG91+wZ67yZ2Y+JCdcJMrQMO8NymBcK7wDnlfCOm+TSpFRsMdi8RIPdAzSBT9LKKBJC+8Ocx\n DHCvn6WJdi9U58lPFkBQ1i5o5Oef8P2pvK/GIwylv+h/FnbmCvRL5OzSA2DNdht5ejz90QePV6F\n GqEVE+qbhDBN61jum2aecbwsFs0KnKK4CK/KQbHn7LFftLEo5dWNgRXTk0HiubJmmaLAtdB3j3s\n CDa3BL3KAkz1kKHEvj6RJRFmyCWNpvFAs1Exp01TUoFdkmaTfROva7jvol1iNgDOqpOFON27L4N\n kzZ8LE2GvneJeHkuFEV5xB84LhZUz0D65S4VcI6lm40tP5/HdJzm7MegN/qaY2/unV9h8RaxYOW\n 5e3KerYU6DAG41SOG8uqsEEh7tJfrZvBO1MCGnbIQyO4S/0V7Bq+zXijyskEzj3bXxJjCCRvFpu\n wahTmoPissmTAqpKiLQ==","X-Proofpoint-ORIG-GUID":"kB3pJ4wLEUyKh3m8mDOvvYKlW5_Xg91H","X-Authority-Analysis":"v=2.4 cv=W60IkxWk c=1 sm=1 tr=0 ts=69dd7f05 cx=c_pps\n a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=VwQbUJbxAAAA:8\n a=VnNF1IyMAAAA:8 a=LI8zkurGpkgCOcO8t2sA:9 a=QEXdDO2ut3YA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-13_03,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n impostorscore=0 clxscore=1015 priorityscore=1501 spamscore=0 bulkscore=0\n adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604130229"}},{"id":3677227,"web_url":"http://patchwork.ozlabs.org/comment/3677227/","msgid":"<20260414081238.23e2cecc@shazbot.org>","list_archive_url":null,"date":"2026-04-14T14:12:38","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":91887,"url":"http://patchwork.ozlabs.org/api/people/91887/","name":"Alex Williamson","email":"alex@shazbot.org"},"content":"On Mon, 13 Apr 2026 16:40:49 -0700\nFarhan Ali wrote:\n\n> On 4/13/2026 3:57 PM, Alex Williamson wrote:\n> > On Mon, 13 Apr 2026 14:06:06 -0700\n> > Farhan Ali wrote:\n> > \n> >> For zPCI devices, we have platform specific error information. The platform\n> >> firmware provides this error information to the operating system in an\n> >> architecture specific mechanism. To enable recovery from userspace for\n> >> these devices, we want to expose this error information to userspace. Add a\n> >> new device feature to expose this information.\n> >>\n> >> Reviewed-by: Matthew Rosato \n> >> Signed-off-by: Farhan Ali \n> >> ---\n> >> arch/s390/include/asm/pci.h | 3 +++\n> >> arch/s390/pci/pci_event.c | 19 +++++++++++++++++++\n> >> drivers/vfio/pci/vfio_pci_core.c | 2 ++\n> >> drivers/vfio/pci/vfio_pci_priv.h | 9 +++++++++\n> >> drivers/vfio/pci/vfio_pci_zdev.c | 31 +++++++++++++++++++++++++++++++\n> >> include/uapi/linux/vfio.h | 20 ++++++++++++++++++++\n> >> 6 files changed, 84 insertions(+)\n> >>\n> >> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h\n> >> index 9a6a4eb9d7c1..9c8ee97d7e8a 100644\n> >> --- a/arch/s390/include/asm/pci.h\n> >> +++ b/arch/s390/include/asm/pci.h\n> >> @@ -360,6 +360,9 @@ int zpci_clear_error_state(struct zpci_dev *zdev);\n> >> int zpci_reset_load_store_blocked(struct zpci_dev *zdev);\n> >> void zpci_start_mediated_recovery(struct zpci_dev *zdev);\n> >> void zpci_stop_mediated_recovery(struct zpci_dev *zdev);\n> >> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n> >> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n> >> +\t\t\t\t int *count);\n> >> \n> >> #ifdef CONFIG_NUMA\n> >> \n> >> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c\n> >> index c279a9f50a64..c8714d4a32fa 100644\n> >> --- a/arch/s390/pci/pci_event.c\n> >> +++ b/arch/s390/pci/pci_event.c\n> >> @@ -74,6 +74,25 @@ static void zpci_store_pci_error(struct pci_dev *pdev,\n> >> \tzdev->pending_errs.count++;\n> >> }\n> >> \n> >> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n> >> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n> >> +\t\t\t\t int *count)\n> >> +{\n> >> +\tint head = 0; \n> > Unnecessary. Should also be a blank line between variable declaration\n> > and code.\n> > \n> >> +\t*count = 0; \n> > But why do we zero this and not ccdf? \n> \n> I had thought of memsetting ccdf to 0, but the only caller right already \n> initializes to 0. So didn't think it was needed.\n\nThe caller initializes count as well.\n\n> >> +\n> >> +\tguard(mutex)(&zdev->pending_errs_lock);\n> >> +\tif (zdev->pending_errs.count) {\n> >> +\t\thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n> >> +\t\tmemcpy(ccdf, &zdev->pending_errs.err[head],\n> >> +\t\t sizeof(struct zpci_ccdf_err));\n> >> +\t\tzdev->pending_errs.head++;\n> >> +\t\tzdev->pending_errs.count--;\n> >> +\t\t*count = zdev->pending_errs.count;\n> >> +\t}\n> >> +} \n> > You've describe in the uAPI now how pec = 0 means no error, but why not\n> > remove that ambiguity altogether and return -ENOMSG in that case. We\n> > could start here and pass it through:\n> >\n> > {\n> > \tint head;\n> >\n> > \tguard(mutex)(&zdev->pending_errs_lock);\n> >\n> > \tif (!zdev->pending_errs.count)\n> > \t\treturn -ENOMSG;\n> >\n> > \thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n> > \tmemcpy(ccdf, &zdev->pending_errs.err[head],\n> > \t sizeof(struct zpci_ccdf_err));\n> > \tzdev->pending_errs.head++;\n> > \tzdev->pending_errs.count--;\n> > \t*count = zdev->pending_errs.count;\n> >\n> > \treturn 0;\n> > } \n> \n> I had thought of returning an error (ENOENT was what I was going with), \n> but perhaps I misunderstood your comment from v12 about specifying pec = \n> 0 and pending error = 0 as not being an error. My assumption was as this \n> is not an error we shouldn't return an error to userspace.\n\nI think I was trying to get clarity on how 0/0 is interpreted because\nit seems like a weak point of the uAPI. We could make a more intuitive\nuAPI if we make the \"I have no message of desired type\" response an\nexplicit, unique errno, rather than a reserved pec value.\n\n> >> +EXPORT_SYMBOL_GPL(zpci_get_pending_error_and_count);\n> >> +\n> >> void zpci_start_mediated_recovery(struct zpci_dev *zdev)\n> >> {\n> >> \tguard(mutex)(&zdev->pending_errs_lock);\n> >> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n> >> index ad52abc46c04..5403730786a1 100644\n> >> --- a/drivers/vfio/pci/vfio_pci_core.c\n> >> +++ b/drivers/vfio/pci/vfio_pci_core.c\n> >> @@ -1534,6 +1534,8 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,\n> >> \t\treturn vfio_pci_core_feature_token(vdev, flags, arg, argsz);\n> >> \tcase VFIO_DEVICE_FEATURE_DMA_BUF:\n> >> \t\treturn vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);\n> >> +\tcase VFIO_DEVICE_FEATURE_ZPCI_ERROR:\n> >> +\t\treturn vfio_pci_zdev_feature_err(device, flags, arg, argsz);\n> >> \tdefault:\n> >> \t\treturn -ENOTTY;\n> >> \t}\n> >> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h\n> >> index fca9d0dfac90..4e7162234a2e 100644\n> >> --- a/drivers/vfio/pci/vfio_pci_priv.h\n> >> +++ b/drivers/vfio/pci/vfio_pci_priv.h\n> >> @@ -93,6 +93,8 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> >> \t\t\t\tstruct vfio_info_cap *caps);\n> >> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);\n> >> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);\n> >> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n> >> +\t\t\t void __user *arg, size_t argsz);\n> >> #else\n> >> static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> >> \t\t\t\t\t struct vfio_info_cap *caps)\n> >> @@ -107,6 +109,13 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n> >> \n> >> static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)\n> >> {}\n> >> +\n> >> +static inline int vfio_pci_zdev_feature_err(struct vfio_device *device,\n> >> +\t\t\t\t\t u32 flags, void __user *arg,\n> >> +\t\t\t\t\t size_t argsz)\n> >> +{\n> >> +\treturn -ENOTTY;\n> >> +}\n> >> #endif\n> >> \n> >> static inline bool vfio_pci_is_vga(struct pci_dev *pdev)\n> >> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c\n> >> index 0658095ac5b1..ee1647f0ffe6 100644\n> >> --- a/drivers/vfio/pci/vfio_pci_zdev.c\n> >> +++ b/drivers/vfio/pci/vfio_pci_zdev.c\n> >> @@ -141,6 +141,37 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n> >> \treturn ret;\n> >> }\n> >> \n> >> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n> >> +\t\t\t void __user *arg, size_t argsz)\n> >> +{\n> >> +\tstruct vfio_device_feature_zpci_err err = {};\n> >> +\tstruct vfio_pci_core_device *vdev;\n> >> +\tstruct zpci_ccdf_err ccdf = {};\n> >> +\tstruct zpci_dev *zdev;\n> >> +\tint pending_errors = 0;\n> >> +\tint ret;\n> >> +\n> >> +\tvdev = container_of(device, struct vfio_pci_core_device, vdev);\n> >> +\tzdev = to_zpci(vdev->pdev);\n> >> +\tif (!zdev)\n> >> +\t\treturn -ENODEV;\n> >> +\n> >> +\tret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,\n> >> +\t\t\t\t sizeof(err));\n> >> +\tif (ret != 1)\n> >> +\t\treturn ret;\n> >> +\n> >> +\tzpci_get_pending_error_and_count(zdev, &ccdf, &pending_errors);\n> >> +\n> >> +\terr.version = 1;\n> >> +\terr.pec = ccdf.pec;\n> >> +\terr.pending_errors = pending_errors;\n> >> +\tif (copy_to_user(arg, &err, sizeof(err)))\n> >> +\t\treturn -EFAULT;\n> >> +\n> >> +\treturn 0;\n> >> +}\n> >> +\n> >> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n> >> {\n> >> \tstruct zpci_dev *zdev = to_zpci(vdev->pdev);\n> >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> >> index 5de618a3a5ee..2980ca39dd38 100644\n> >> --- a/include/uapi/linux/vfio.h\n> >> +++ b/include/uapi/linux/vfio.h\n> >> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n> >> */\n> >> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n> >> \n> >> +/**\n> >> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n> >> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n> >> + * involves platform firmware and notification to operating system is done\n> >> + * by architecture specific mechanism. Exposing this information to\n> >> + * userspace allows it to take appropriate actions to handle an\n> >> + * error on the device. The pending_errors provide any additional errors\n> >> + * pending for the device, and userspace should read until zero. A value of\n> >> + * 0 for pending_errors and pec would indicate no pending errors that need\n> >> + * to be handled.\n> >> + */\n> >> +\n> >> +struct vfio_device_feature_zpci_err {\n> >> +\t__u8 version;\n> >> +\t__u8 pending_errors;\n> >> +\t__u16 pec;\n> >> +}; \n> > I assume .version is for compatibility, but we don't define a strategy\n> > for using it or specify what the version should be for this table. It\n> > doesn't seem like there's actually an value-add to having it. \n> \n> Its possible we may need to extend this structure in the future if we \n> want to report more information to userspace. I at least want the \n> flexibility to do so. We had some discussion around this [1] in an \n> earlier version. I was trying to follow similar versioning pattern we \n> had around vfio-pci/zdev structures.\n\nIMHO, the version field is a dead end towards achieving this,\nespecially if we don't specify from the onset the expected version\nvalue or the compatibility semantics. All that's going to happen is\nthat some userspace will hard code that it understands version 1\nbecause that's what's currently reported and matches the struct defined\nhere, and you can never ever report anything other than version 1\nwithout breaking that user. At that point you need to come up with\nsome other means for the user to opt-in to a new version, whether it's\ntriggered by another feature (as we did with the PRECOPY_INFOv2 above\nthis), or we reimplement the whole v2 feature.\n\n> > I'm also not clear why we need to report .pending_errors. It mostly\n> > seems like another ambiguous feature of this API. The value seems\n> > volatile and the suggestion is to read until zero, so why provide the\n> > value at all, the user can just read until -ENOMSG. \n> \n> Since we don't explicitly return an error indicating there are no \n> available pci errors to handle, was why I added it. Is the preference to \n> just return linux error code here?\n\nI think that can be interpreted as the .pending_errors field exists to\nwork around a deficiency in the uAPI rather than modifying the uAPI to\nsomething that can explicitly return -ENOMSG. Feels like we should\njust start with a better uAPI. Thanks,\n\nAlex","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=shazbot.org header.i=@shazbot.org header.a=rsa-sha256\n header.s=fm1 header.b=Mvh+ZeAR;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=sqLeKJEv;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-52491-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=\"Mvh+ZeAR\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"sqLeKJEv\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.12.124.156","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=shazbot.org"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw5r55270z1xtJ\n\tfor ; Wed, 15 Apr 2026 00:14:29 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 6DC62302239D\n\tfor ; Tue, 14 Apr 2026 14:12:51 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C43543E8684;\n\tTue, 14 Apr 2026 14:12:46 +0000 (UTC)","from fhigh-b5-smtp.messagingengine.com\n (fhigh-b5-smtp.messagingengine.com [202.12.124.156])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 65D653E7174;\n\tTue, 14 Apr 2026 14:12:43 +0000 (UTC)","from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46])\n\tby mailfhigh.stl.internal (Postfix) with ESMTP id 477997A016A;\n\tTue, 14 Apr 2026 10:12:42 -0400 (EDT)","from phl-frontend-04 ([10.202.2.163])\n by phl-compute-06.internal (MEProxy); Tue, 14 Apr 2026 10:12:42 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Tue,\n 14 Apr 2026 10:12:40 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776175966; cv=none;\n b=IjcHI4S3lZ0iXNlo/kpOb9uc2+fKh9ArtYrFg/5J6d3t1kOx/QRWGm6B3j4smCMW0ERxyXkSwjvU8BewVpiNWV0+OYVRutl+2phbnrhPPIBqgryviD9s961aIkA+cg3IDuY5G02OblsVhi0R3huLXj7z8o0AsjfdoI9SYl3fprg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776175966; c=relaxed/simple;\n\tbh=uAVJpJnZIO7KMMB/lw9nwEAyap4Nw8wh6yxkAuFuE+o=;\n\th=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:\n\t MIME-Version:Content-Type;\n b=ktssHip6aPr+kjjrTfcWsj4az1T9BlNdKW3FG8tiethKQ/e2Ygow/VNM8FGPpIrtljo1czqeqFF+WVqcD+Afp8sIErY8nZ8xJpl+JRm91BAgG9a71S5GIuHyBeTRw2KWP22LSrJfgeSY7wDb+cOCmo9/PsHLgqndD5496gsWvyM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org;\n spf=pass smtp.mailfrom=shazbot.org;\n dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=Mvh+ZeAR;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=sqLeKJEv; arc=none smtp.client-ip=202.12.124.156","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=shazbot.org; h=\n\tcc:cc:content-transfer-encoding:content-type:content-type:date\n\t:date:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to; s=fm1; t=1776175962;\n\t x=1776262362; bh=qCvEqJRBfyR4i0siTqFXO2296KUNeGvlyJV4drI5uw0=; b=\n\tMvh+ZeARXPjR10qPXOrSxEFATokBy45AKtJHb6u2cuKr9mOWq3ws1SutzxomogKO\n\tN46TVFpM1JxO3h6jcR8D5qIh0INdJHOA3+l6TcXrGrGoxB/tR/7Y9p5sCISBJT1Y\n\teQeZ3oZH35+mpTrUAu+kTyHz3EoH1Maky8885NzaurOu+eDzYVOKmrvIEEP/8+73\n\tZPvNEtl4GdjHzpFZks7GIr5hEHaq+fPKnVR9q7EVVXGz91CMwpdKtodnHXRUE1dP\n\t6FM5MA2a/nU4SaVTlwTjDCA4cFVXLB32Q18rccMHHnKlTUC6Xj3qxerdoPKAn8SR\n\tVGMXkeY0Syvv1LQ6l/F7mg==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:cc:content-transfer-encoding\n\t:content-type:content-type:date:date:feedback-id:feedback-id\n\t:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to:x-me-proxy\n\t:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1776175962; x=\n\t1776262362; bh=qCvEqJRBfyR4i0siTqFXO2296KUNeGvlyJV4drI5uw0=; b=s\n\tqLeKJEvR2ft5njB02SO2wg3+OW+bydW9zI6xRNlm3awpKHAacB6QvghQVhcHwGpf\n\tfdZg+wlo3Y+oizxEGKdW0srQGC/dAlmH6A5EJCkK12cLvnohnAkX8C8wVUICFnbX\n\ttGNZG6Jw0dbgyV/7x4eVk168ZkY7rFwWQNozeLuwXgzhWWGRJ0RYYcMroq0RD1bZ\n\tk4vRby1M9X7D3TckVhGMcY1gwEmsZDHFHbnaiFQwVG9/AcZn7Cx++UpX1zDscGV6\n\t8gb5xVbqdkS21gw8r0acRARRsj3ZhBw7165vjjrCvDk6ppa9lpMsYpXxVsjhJ+O2\n\tD041b1DgWmYubqCjt3+Tw=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdegudefiecutefuodetggdotefrod\n ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n ihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkjghfofggtgfgsehtjeertd\n ertddvnecuhfhrohhmpeetlhgvgicuhghilhhlihgrmhhsohhnuceorghlvgigsehshhgr\n iigsohhtrdhorhhgqeenucggtffrrghtthgvrhhnpedvkeefjeekvdduhfduhfetkedugf\n duieettedvueekvdehtedvkefgudegveeuueenucevlhhushhtvghrufhiiigvpedtnecu\n rfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgiesshhhrgiisghothdrohhrghdpnhgspg\n hrtghpthhtohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrlhhifhhm\n sehlihhnuhigrdhisghmrdgtohhmpdhrtghpthhtoheplhhinhhugidqshefledtsehvgh\n gvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehv\n ghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphgtihesvhhgvg\n hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehhvghlghgrrghssehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehluhhkrghsseifuhhnnhgvrhdruggvpdhrtghpthhtoheptg\n hlghesrhgvughhrghtrdgtohhmpdhrtghpthhtohepkhgsuhhstghhsehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehstghhnhgvlhhlvgeslhhinhhugidrihgsmhdrtghomh","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"i03f14258:Fastmail","Date":"Tue, 14 Apr 2026 08:12:38 -0600","From":"Alex Williamson ","To":"Farhan Ali ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com, alex@shazbot.org","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","Message-ID":"<20260414081238.23e2cecc@shazbot.org>","In-Reply-To":"","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n\t<20260413210608.2912-6-alifm@linux.ibm.com>\n\t<20260413165758.0f87312b@shazbot.org>\n\t","X-Mailer":"Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":3677324,"web_url":"http://patchwork.ozlabs.org/comment/3677324/","msgid":"<5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>","list_archive_url":null,"date":"2026-04-14T17:13:22","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":73785,"url":"http://patchwork.ozlabs.org/api/people/73785/","name":"Farhan Ali","email":"alifm@linux.ibm.com"},"content":"On 4/14/2026 7:12 AM, Alex Williamson wrote:\n> On Mon, 13 Apr 2026 16:40:49 -0700\n> Farhan Ali wrote:\n>\n>> On 4/13/2026 3:57 PM, Alex Williamson wrote:\n>>> On Mon, 13 Apr 2026 14:06:06 -0700\n>>> Farhan Ali wrote:\n>>> \n>>>> For zPCI devices, we have platform specific error information. The platform\n>>>> firmware provides this error information to the operating system in an\n>>>> architecture specific mechanism. To enable recovery from userspace for\n>>>> these devices, we want to expose this error information to userspace. Add a\n>>>> new device feature to expose this information.\n>>>>\n>>>> Reviewed-by: Matthew Rosato \n>>>> Signed-off-by: Farhan Ali \n>>>> ---\n>>>> arch/s390/include/asm/pci.h | 3 +++\n>>>> arch/s390/pci/pci_event.c | 19 +++++++++++++++++++\n>>>> drivers/vfio/pci/vfio_pci_core.c | 2 ++\n>>>> drivers/vfio/pci/vfio_pci_priv.h | 9 +++++++++\n>>>> drivers/vfio/pci/vfio_pci_zdev.c | 31 +++++++++++++++++++++++++++++++\n>>>> include/uapi/linux/vfio.h | 20 ++++++++++++++++++++\n>>>> 6 files changed, 84 insertions(+)\n>>>>\n>>>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h\n>>>> index 9a6a4eb9d7c1..9c8ee97d7e8a 100644\n>>>> --- a/arch/s390/include/asm/pci.h\n>>>> +++ b/arch/s390/include/asm/pci.h\n>>>> @@ -360,6 +360,9 @@ int zpci_clear_error_state(struct zpci_dev *zdev);\n>>>> int zpci_reset_load_store_blocked(struct zpci_dev *zdev);\n>>>> void zpci_start_mediated_recovery(struct zpci_dev *zdev);\n>>>> void zpci_stop_mediated_recovery(struct zpci_dev *zdev);\n>>>> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n>>>> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n>>>> +\t\t\t\t int *count);\n>>>> \n>>>> #ifdef CONFIG_NUMA\n>>>> \n>>>> diff --git a/arch/s390/pci/pci_event.c b/arch/s390/pci/pci_event.c\n>>>> index c279a9f50a64..c8714d4a32fa 100644\n>>>> --- a/arch/s390/pci/pci_event.c\n>>>> +++ b/arch/s390/pci/pci_event.c\n>>>> @@ -74,6 +74,25 @@ static void zpci_store_pci_error(struct pci_dev *pdev,\n>>>> \tzdev->pending_errs.count++;\n>>>> }\n>>>> \n>>>> +void zpci_get_pending_error_and_count(struct zpci_dev *zdev,\n>>>> +\t\t\t\t struct zpci_ccdf_err *ccdf,\n>>>> +\t\t\t\t int *count)\n>>>> +{\n>>>> +\tint head = 0;\n>>> Unnecessary. Should also be a blank line between variable declaration\n>>> and code.\n>>> \n>>>> +\t*count = 0;\n>>> But why do we zero this and not ccdf?\n>> I had thought of memsetting ccdf to 0, but the only caller right already\n>> initializes to 0. So didn't think it was needed.\n> The caller initializes count as well.\n>\n>>>> +\n>>>> +\tguard(mutex)(&zdev->pending_errs_lock);\n>>>> +\tif (zdev->pending_errs.count) {\n>>>> +\t\thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n>>>> +\t\tmemcpy(ccdf, &zdev->pending_errs.err[head],\n>>>> +\t\t sizeof(struct zpci_ccdf_err));\n>>>> +\t\tzdev->pending_errs.head++;\n>>>> +\t\tzdev->pending_errs.count--;\n>>>> +\t\t*count = zdev->pending_errs.count;\n>>>> +\t}\n>>>> +}\n>>> You've describe in the uAPI now how pec = 0 means no error, but why not\n>>> remove that ambiguity altogether and return -ENOMSG in that case. We\n>>> could start here and pass it through:\n>>>\n>>> {\n>>> \tint head;\n>>>\n>>> \tguard(mutex)(&zdev->pending_errs_lock);\n>>>\n>>> \tif (!zdev->pending_errs.count)\n>>> \t\treturn -ENOMSG;\n>>>\n>>> \thead = zdev->pending_errs.head % ZPCI_ERR_PENDING_MAX;\n>>> \tmemcpy(ccdf, &zdev->pending_errs.err[head],\n>>> \t sizeof(struct zpci_ccdf_err));\n>>> \tzdev->pending_errs.head++;\n>>> \tzdev->pending_errs.count--;\n>>> \t*count = zdev->pending_errs.count;\n>>>\n>>> \treturn 0;\n>>> }\n>> I had thought of returning an error (ENOENT was what I was going with),\n>> but perhaps I misunderstood your comment from v12 about specifying pec =\n>> 0 and pending error = 0 as not being an error. My assumption was as this\n>> is not an error we shouldn't return an error to userspace.\n> I think I was trying to get clarity on how 0/0 is interpreted because\n> it seems like a weak point of the uAPI. We could make a more intuitive\n> uAPI if we make the \"I have no message of desired type\" response an\n> explicit, unique errno, rather than a reserved pec value.\n>\n>>>> +EXPORT_SYMBOL_GPL(zpci_get_pending_error_and_count);\n>>>> +\n>>>> void zpci_start_mediated_recovery(struct zpci_dev *zdev)\n>>>> {\n>>>> \tguard(mutex)(&zdev->pending_errs_lock);\n>>>> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c\n>>>> index ad52abc46c04..5403730786a1 100644\n>>>> --- a/drivers/vfio/pci/vfio_pci_core.c\n>>>> +++ b/drivers/vfio/pci/vfio_pci_core.c\n>>>> @@ -1534,6 +1534,8 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,\n>>>> \t\treturn vfio_pci_core_feature_token(vdev, flags, arg, argsz);\n>>>> \tcase VFIO_DEVICE_FEATURE_DMA_BUF:\n>>>> \t\treturn vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);\n>>>> +\tcase VFIO_DEVICE_FEATURE_ZPCI_ERROR:\n>>>> +\t\treturn vfio_pci_zdev_feature_err(device, flags, arg, argsz);\n>>>> \tdefault:\n>>>> \t\treturn -ENOTTY;\n>>>> \t}\n>>>> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h\n>>>> index fca9d0dfac90..4e7162234a2e 100644\n>>>> --- a/drivers/vfio/pci/vfio_pci_priv.h\n>>>> +++ b/drivers/vfio/pci/vfio_pci_priv.h\n>>>> @@ -93,6 +93,8 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>>>> \t\t\t\tstruct vfio_info_cap *caps);\n>>>> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);\n>>>> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);\n>>>> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n>>>> +\t\t\t void __user *arg, size_t argsz);\n>>>> #else\n>>>> static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>>>> \t\t\t\t\t struct vfio_info_cap *caps)\n>>>> @@ -107,6 +109,13 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n>>>> \n>>>> static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)\n>>>> {}\n>>>> +\n>>>> +static inline int vfio_pci_zdev_feature_err(struct vfio_device *device,\n>>>> +\t\t\t\t\t u32 flags, void __user *arg,\n>>>> +\t\t\t\t\t size_t argsz)\n>>>> +{\n>>>> +\treturn -ENOTTY;\n>>>> +}\n>>>> #endif\n>>>> \n>>>> static inline bool vfio_pci_is_vga(struct pci_dev *pdev)\n>>>> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c\n>>>> index 0658095ac5b1..ee1647f0ffe6 100644\n>>>> --- a/drivers/vfio/pci/vfio_pci_zdev.c\n>>>> +++ b/drivers/vfio/pci/vfio_pci_zdev.c\n>>>> @@ -141,6 +141,37 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,\n>>>> \treturn ret;\n>>>> }\n>>>> \n>>>> +int vfio_pci_zdev_feature_err(struct vfio_device *device, u32 flags,\n>>>> +\t\t\t void __user *arg, size_t argsz)\n>>>> +{\n>>>> +\tstruct vfio_device_feature_zpci_err err = {};\n>>>> +\tstruct vfio_pci_core_device *vdev;\n>>>> +\tstruct zpci_ccdf_err ccdf = {};\n>>>> +\tstruct zpci_dev *zdev;\n>>>> +\tint pending_errors = 0;\n>>>> +\tint ret;\n>>>> +\n>>>> +\tvdev = container_of(device, struct vfio_pci_core_device, vdev);\n>>>> +\tzdev = to_zpci(vdev->pdev);\n>>>> +\tif (!zdev)\n>>>> +\t\treturn -ENODEV;\n>>>> +\n>>>> +\tret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,\n>>>> +\t\t\t\t sizeof(err));\n>>>> +\tif (ret != 1)\n>>>> +\t\treturn ret;\n>>>> +\n>>>> +\tzpci_get_pending_error_and_count(zdev, &ccdf, &pending_errors);\n>>>> +\n>>>> +\terr.version = 1;\n>>>> +\terr.pec = ccdf.pec;\n>>>> +\terr.pending_errors = pending_errors;\n>>>> +\tif (copy_to_user(arg, &err, sizeof(err)))\n>>>> +\t\treturn -EFAULT;\n>>>> +\n>>>> +\treturn 0;\n>>>> +}\n>>>> +\n>>>> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)\n>>>> {\n>>>> \tstruct zpci_dev *zdev = to_zpci(vdev->pdev);\n>>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n>>>> index 5de618a3a5ee..2980ca39dd38 100644\n>>>> --- a/include/uapi/linux/vfio.h\n>>>> +++ b/include/uapi/linux/vfio.h\n>>>> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n>>>> */\n>>>> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n>>>> \n>>>> +/**\n>>>> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n>>>> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n>>>> + * involves platform firmware and notification to operating system is done\n>>>> + * by architecture specific mechanism. Exposing this information to\n>>>> + * userspace allows it to take appropriate actions to handle an\n>>>> + * error on the device. The pending_errors provide any additional errors\n>>>> + * pending for the device, and userspace should read until zero. A value of\n>>>> + * 0 for pending_errors and pec would indicate no pending errors that need\n>>>> + * to be handled.\n>>>> + */\n>>>> +\n>>>> +struct vfio_device_feature_zpci_err {\n>>>> +\t__u8 version;\n>>>> +\t__u8 pending_errors;\n>>>> +\t__u16 pec;\n>>>> +};\n>>> I assume .version is for compatibility, but we don't define a strategy\n>>> for using it or specify what the version should be for this table. It\n>>> doesn't seem like there's actually an value-add to having it.\n>> Its possible we may need to extend this structure in the future if we\n>> want to report more information to userspace. I at least want the\n>> flexibility to do so. We had some discussion around this [1] in an\n>> earlier version. I was trying to follow similar versioning pattern we\n>> had around vfio-pci/zdev structures.\n> IMHO, the version field is a dead end towards achieving this,\n> especially if we don't specify from the onset the expected version\n> value or the compatibility semantics. All that's going to happen is\n> that some userspace will hard code that it understands version 1\n> because that's what's currently reported and matches the struct defined\n> here, and you can never ever report anything other than version 1\n> without breaking that user. At that point you need to come up with\n> some other means for the user to opt-in to a new version, whether it's\n> triggered by another feature (as we did with the PRECOPY_INFOv2 above\n> this), or we reimplement the whole v2 feature.\n\nMy understanding was based on how we version some of the capability \nstructures for zdev (in include/uapi/linux/vfio_zdev.h). If we wanted to \nprovide more information to userspace in the future, what would be \npreferred approach? Do we need to explicitly define a v2 feature? I am \nopen to suggestions on this.\n\nIf we need to define v2 explicitly in the future, then yes I agree we \ncan simplify it to return only the PEC code (or an error code otherwise).\n\nThanks\n\nFarhan","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=STpB5DRA;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52513-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"STpB5DRA\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.156.1","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fw9y21dxDz1yCv\n\tfor ; Wed, 15 Apr 2026 03:19:54 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 5727B3096260\n\tfor ; Tue, 14 Apr 2026 17:13:34 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A39662F5491;\n\tTue, 14 Apr 2026 17:13:33 +0000 (UTC)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 10D3040DFC3;\n\tTue, 14 Apr 2026 17:13:31 +0000 (UTC)","from pps.filterd (m0360083.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63EES5Su2130784;\n\tTue, 14 Apr 2026 17:13:25 GMT","from ppma22.wdc07v.mail.ibm.com\n (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89nc1j3-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 17:13:25 +0000 (GMT)","from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])\n\tby ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63EGxrGu031854;\n\tTue, 14 Apr 2026 17:13:24 GMT","from smtprelay07.dal12v.mail.ibm.com ([172.16.1.9])\n\tby ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4dg10yaqpe-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 17:13:24 +0000","from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com\n [10.241.53.104])\n\tby smtprelay07.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63EHDNne32178846\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tTue, 14 Apr 2026 17:13:23 GMT","from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 2EA6058068;\n\tTue, 14 Apr 2026 17:13:23 +0000 (GMT)","from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 6F4A958052;\n\tTue, 14 Apr 2026 17:13:22 +0000 (GMT)","from [9.61.240.138] (unknown [9.61.240.138])\n\tby smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP;\n\tTue, 14 Apr 2026 17:13:22 +0000 (GMT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776186813; cv=none;\n b=aK9RId/cNbkOzPFdoT8icsWQWQgHUl/nDXL3UH3lOShNof+s8714KMCZIGf/pbtvGiTT5mGiLNTVX0TFjLt1RD6hj8bK0/IcoA/6FGpPP/lBWvFynztl0dM4adWGVqP1qA0OpoWg7ovMMIWdEajGRD6mM/qtjw+Ch1xQrdJuTi8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776186813; c=relaxed/simple;\n\tbh=JIs3S8VJmzGgcEtg/fL5H1IJoqYEvBQtZcGWw35xduc=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=NplehN99S4wYxTwrY0EmMAQYgtWi4da732Z8izLcCFiwGlj9rFsNimgcFTSPK0ufxtOb51J7cvjDRBXHw2njwawd9exHRkdbDfLuYNy3bt7il4DohtwZBkaxPdzQDpALXMJSjDQSh7HQf+QbfGhuJLNV3xx3AA+0NvW9i+wjVw4=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=STpB5DRA; arc=none smtp.client-ip=148.163.156.1","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=pp1; bh=ttdH+t\n\thrBHwcVWodbjtWfYyN1VUGbaMvuy2Q/IkdChE=; b=STpB5DRAJuJE/jUbCrvZ+p\n\tkfJ81bywWmr+G6oElSGPWV+5Qr7C/W1/aoLJ7erPCCDOZ8xpoRwYV3kjiQ66oQat\n\tf51bUGy2Ta6Hrc3h0ZyQKQFDbs/1AtSDvVYuJJl3LUX0rm4QBf4gkmGgOwTisYy7\n\tXxxnqjrkDiyufaDO2AxXYX1RAeIkik0NUYKTwax0b58VQ/BlBAaju/d8lzE3Qykt\n\tVKrfrGSNFW41os0SDHP7T3/SYpx5a1tUu1I3bpFiaQisd3YfdIoAv8JTSiVE0KI7\n\tOofH11OCpOgCV6bp5QgixjfHcAcLpsjdZg1SYYmYjbBIyw8gGg1JMo71Kz4joI1Q\n\t==","Message-ID":"<5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>","Date":"Tue, 14 Apr 2026 10:13:22 -0700","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","To":"Alex Williamson ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n <20260413210608.2912-6-alifm@linux.ibm.com>\n <20260413165758.0f87312b@shazbot.org>\n \n <20260414081238.23e2cecc@shazbot.org>","Content-Language":"en-US","From":"Farhan Ali ","In-Reply-To":"<20260414081238.23e2cecc@shazbot.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","X-Proofpoint-GUID":"01iS5vQT8wITVg0m5U5jguN7VnKMHDiu","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE0MDE1NyBTYWx0ZWRfXyRjflQ0PREqg\n ztLZMgld3FAUhRi8uPByT2oJ7/3BKsacUTGFkNOZsJDVRWqS2IzTDeXHuJeuzmOXN1CPiuGlVVA\n rWbOyvy8kjuvO0YZS/K6B/+srEkiom9/Duf3+54LQZIb9XbTHU9RwWCWY27TN5jEM+g3gD5tYLc\n vKhu3TY0MSbTX3+XbqY5md9+wPDkdMv5WeLrShYkKaIqN6jhQN2m1znuJoUUFIfPfON7WAzEOlz\n A4vq4ped8C8ZNtq8m5l2lLZMWm5JOKyGAMTX0SfaqVmloU9KAt9Iy5jtSnhoc5l5FfXqbVYx8YE\n qO515Cb8PfTKKBPaHl7o0i1ZQF8xCxp/tOp/JWvAaPmOeR2Cipf55c6qMRvAALmW2UddqLBROfv\n 6ckw74QYalq+nZpiWxlTxjYM4vXwugtnqRwIYtVTkE1ND/JQoaprjYcXOAZYgUL8pWgio+qGBLc\n IUW6+vzAxR7jH58uNfQ==","X-Proofpoint-ORIG-GUID":"01iS5vQT8wITVg0m5U5jguN7VnKMHDiu","X-Authority-Analysis":"v=2.4 cv=FY4HAp+6 c=1 sm=1 tr=0 ts=69de75b5 cx=c_pps\n a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=VnNF1IyMAAAA:8\n a=zt6kzwg4mn7V0aSmamUA:9 a=QEXdDO2ut3YA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-14_03,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n adultscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0\n lowpriorityscore=0 suspectscore=0 clxscore=1015 malwarescore=0 phishscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140157"}},{"id":3677333,"web_url":"http://patchwork.ozlabs.org/comment/3677333/","msgid":"<20260414114132.31481b48@shazbot.org>","list_archive_url":null,"date":"2026-04-14T17:41:32","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":91887,"url":"http://patchwork.ozlabs.org/api/people/91887/","name":"Alex Williamson","email":"alex@shazbot.org"},"content":"On Tue, 14 Apr 2026 10:13:22 -0700\nFarhan Ali wrote:\n> On 4/14/2026 7:12 AM, Alex Williamson wrote:\n> > On Mon, 13 Apr 2026 16:40:49 -0700\n> > Farhan Ali wrote:\n> >> On 4/13/2026 3:57 PM, Alex Williamson wrote: \n> >>> On Mon, 13 Apr 2026 14:06:06 -0700\n> >>> Farhan Ali wrote:\n> >>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> >>>> index 5de618a3a5ee..2980ca39dd38 100644\n> >>>> --- a/include/uapi/linux/vfio.h\n> >>>> +++ b/include/uapi/linux/vfio.h\n> >>>> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n> >>>> */\n> >>>> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n> >>>> \n> >>>> +/**\n> >>>> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n> >>>> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n> >>>> + * involves platform firmware and notification to operating system is done\n> >>>> + * by architecture specific mechanism. Exposing this information to\n> >>>> + * userspace allows it to take appropriate actions to handle an\n> >>>> + * error on the device. The pending_errors provide any additional errors\n> >>>> + * pending for the device, and userspace should read until zero. A value of\n> >>>> + * 0 for pending_errors and pec would indicate no pending errors that need\n> >>>> + * to be handled.\n> >>>> + */\n> >>>> +\n> >>>> +struct vfio_device_feature_zpci_err {\n> >>>> +\t__u8 version;\n> >>>> +\t__u8 pending_errors;\n> >>>> +\t__u16 pec;\n> >>>> +}; \n> >>> I assume .version is for compatibility, but we don't define a strategy\n> >>> for using it or specify what the version should be for this table. It\n> >>> doesn't seem like there's actually an value-add to having it. \n> >> Its possible we may need to extend this structure in the future if we\n> >> want to report more information to userspace. I at least want the\n> >> flexibility to do so. We had some discussion around this [1] in an\n> >> earlier version. I was trying to follow similar versioning pattern we\n> >> had around vfio-pci/zdev structures. \n> > IMHO, the version field is a dead end towards achieving this,\n> > especially if we don't specify from the onset the expected version\n> > value or the compatibility semantics. All that's going to happen is\n> > that some userspace will hard code that it understands version 1\n> > because that's what's currently reported and matches the struct defined\n> > here, and you can never ever report anything other than version 1\n> > without breaking that user. At that point you need to come up with\n> > some other means for the user to opt-in to a new version, whether it's\n> > triggered by another feature (as we did with the PRECOPY_INFOv2 above\n> > this), or we reimplement the whole v2 feature. \n> \n> My understanding was based on how we version some of the capability \n> structures for zdev (in include/uapi/linux/vfio_zdev.h). If we wanted to \n> provide more information to userspace in the future, what would be \n> preferred approach? Do we need to explicitly define a v2 feature? I am \n> open to suggestions on this.\n> \n> If we need to define v2 explicitly in the future, then yes I agree we \n> can simplify it to return only the PEC code (or an error code otherwise).\n\nMaybe I'm reading too much into it, but it sounds like you already have\nplans to expand this.\n\nThe existing zdev structures seem to rely on the version field in the\ncapability header and maybe you've gotten away with bumping the version\nwithout breaking userspace, but it's fragile. AFAICT, the ioctls do not\ndefine a versioning strategy where vN+1 only adds fields to vN, so all\nit takes is one outspoken userspace tool that hard codes its\ncompatibility to a specific version to become a problem for further\nupdates.\n\nLikewise this feature doesn't define a versioning policy for userspace\nto follow. I'm sure there are other examples within vfio that are\nproblematic, but let's try not to create more.\n\nIf you want to use a version, then also define what the version is and\nwhat the compatibility policy is for future versions. A flags field is\nanother option that we've used extensively in vfio. The version field\nmight be better for incremental expansion of the structure, while flags\ncan address specific fields more directly, ex. a reserved field being\nredefined. Thanks,\n\nAlex","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=shazbot.org header.i=@shazbot.org header.a=rsa-sha256\n header.s=fm1 header.b=gx+g2Dbo;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=messagingengine.com header.i=@messagingengine.com\n header.a=rsa-sha256 header.s=fm2 header.b=HAzsvaoW;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52515-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=\"gx+g2Dbo\";\n\tdkim=pass (2048-bit key) header.d=messagingengine.com\n header.i=@messagingengine.com header.b=\"HAzsvaoW\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.12.124.146","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=shazbot.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwBV91R1Fz1xtJ\n\tfor ; Wed, 15 Apr 2026 03:44:17 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id EA237307C3A0\n\tfor ; Tue, 14 Apr 2026 17:41:40 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D68AF3F0762;\n\tTue, 14 Apr 2026 17:41:39 +0000 (UTC)","from fout-b3-smtp.messagingengine.com\n (fout-b3-smtp.messagingengine.com [202.12.124.146])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id BADF83EDAD1;\n\tTue, 14 Apr 2026 17:41:36 +0000 (UTC)","from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45])\n\tby mailfout.stl.internal (Postfix) with ESMTP id 905671D00085;\n\tTue, 14 Apr 2026 13:41:35 -0400 (EDT)","from phl-frontend-04 ([10.202.2.163])\n by phl-compute-05.internal (MEProxy); Tue, 14 Apr 2026 13:41:36 -0400","by mail.messagingengine.com (Postfix) with ESMTPA; Tue,\n 14 Apr 2026 13:41:34 -0400 (EDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776188499; cv=none;\n b=jbLzStKrmLCJ626HsDrXtry72Jh9AmXiPWKOOtGXLvZVpi649XmIu231pzWPrcEs5O0GGlawdCqMDLYTr/HwSiRqo+fhwGCTuW3BL6WKXTsBv0mZ9U6sbnORUrvhuF2l2Bv0W/WbRagcNqb+HZCqV+WV+0sr0Ihy01pg5nFAx/c=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776188499; c=relaxed/simple;\n\tbh=w3Xttz0mTZ9+NRZZK9H73XaJh7kFuAwsAauzXXPCLQc=;\n\th=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:\n\t MIME-Version:Content-Type;\n b=g1UUxoF9otuXvkj2Wu3pYi86x+dRlV4+scd1n7Q/6SrqBCyz6GupS21UVQ/UtzoqEyFteljwWTTyrPvG5urerNx9pWRK01vBui0HteEj3rJuSjur6CyDDAKgQU58oTrGTLnU6Kd0P3LH4OaBarfb4LYNWg9QIhOH+MrfJaZ1uhs=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=shazbot.org;\n spf=pass smtp.mailfrom=shazbot.org;\n dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org\n header.b=gx+g2Dbo;\n dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com\n header.b=HAzsvaoW; arc=none smtp.client-ip=202.12.124.146","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=shazbot.org; h=\n\tcc:cc:content-transfer-encoding:content-type:content-type:date\n\t:date:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to; s=fm1; t=1776188495;\n\t x=1776274895; bh=cIMYB3Vw1R1mczbcWN3ySXUNmPECAiAiyrHdvAbF5OY=; b=\n\tgx+g2DboglzkwLnfVfmWAdBR9zPG3JGhBiku8eSh1ltH/l+A70SLd9ndmA3EKEl2\n\tpPg4T8agrPZAJDET0bCtzPyEcylMgXvvqcp1f/Dwrw7M0gNsPSCIzXuC4zLk/rHn\n\tasgC8IQBMNml1x9Zl61Lp+PE9gQhy3mkHjIARw/MZCqpc0X6wjC6ZxlGbLbmM7mb\n\tjUV37MMjL3rCfNA+iDqt1zOYTkhYGdhXhI8oCgst7Dr9SYe0+vmUt28O+Dvf7i5q\n\tf6Wj6bahZk6HXa6EJyrSrvpeQX8Qv3WgB7/MptIBXar5cqP15zTZijzdU1bb+WfA\n\tbh0/ajdlXaW2daRS6ct3og==","v=1; a=rsa-sha256; c=relaxed/relaxed; d=\n\tmessagingengine.com; h=cc:cc:content-transfer-encoding\n\t:content-type:content-type:date:date:feedback-id:feedback-id\n\t:from:from:in-reply-to:in-reply-to:message-id:mime-version\n\t:references:reply-to:subject:subject:to:to:x-me-proxy\n\t:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1776188495; x=\n\t1776274895; bh=cIMYB3Vw1R1mczbcWN3ySXUNmPECAiAiyrHdvAbF5OY=; b=H\n\tAzsvaoWGjjs/C1p+pVsELlgTkIQW+ecKYgF5qJZHpXnadrgJHEPdFvcCgr3fC8SB\n\t+V1etI1oeFn4qZ3ODyYD4UiAaLpoz17ll2Ik0fXc86UDjry9zuVat9yVXdxWmTIn\n\trZ45N48fTLkhwi3ZQsia7KXFm2DYN4Wslfon1XHtaXvE8qLAJ7MdqOLuEIcd1xNy\n\tEHuHZqtBHx/rllGY2XjmYkxTIYF3XHEl4gGVSUOWTiBfE8uBT9cCrp5T20uMdoXe\n\t9z2H5F+wjwwRg34LaJ2LIZ+G1X5K8LePpelgyCIiOEwQCqRVutecc8ULDsxV6QAk\n\tE6GuFFQ7r3Rxm3HNey3hQ=="],"X-ME-Sender":"\n ","X-ME-Received":"\n ","X-ME-Proxy-Cause":"\n gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdegudejlecutefuodetggdotefrod\n ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr\n ihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkjghfofggtgfgsehtjeertd\n ertddvnecuhfhrohhmpeetlhgvgicuhghilhhlihgrmhhsohhnuceorghlvgigsehshhgr\n iigsohhtrdhorhhgqeenucggtffrrghtthgvrhhnpedvkeefjeekvdduhfduhfetkedugf\n duieettedvueekvdehtedvkefgudegveeuueenucevlhhushhtvghrufhiiigvpedtnecu\n rfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgiesshhhrgiisghothdrohhrghdpnhgspg\n hrtghpthhtohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrlhhifhhm\n sehlihhnuhigrdhisghmrdgtohhmpdhrtghpthhtoheplhhinhhugidqshefledtsehvgh\n gvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehv\n ghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphgtihesvhhgvg\n hrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehhvghlghgrrghssehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehluhhkrghsseifuhhnnhgvrhdruggvpdhrtghpthhtoheptg\n hlghesrhgvughhrghtrdgtohhmpdhrtghpthhtohepkhgsuhhstghhsehkvghrnhgvlhdr\n ohhrghdprhgtphhtthhopehstghhnhgvlhhlvgeslhhinhhugidrihgsmhdrtghomh","X-ME-Proxy":"\n \n \n \n ","Feedback-ID":"i03f14258:Fastmail","Date":"Tue, 14 Apr 2026 11:41:32 -0600","From":"Alex Williamson ","To":"Farhan Ali ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com, alex@shazbot.org","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","Message-ID":"<20260414114132.31481b48@shazbot.org>","In-Reply-To":"<5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n\t<20260413210608.2912-6-alifm@linux.ibm.com>\n\t<20260413165758.0f87312b@shazbot.org>\n\t\n\t<20260414081238.23e2cecc@shazbot.org>\n\t<5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>","X-Mailer":"Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit"}},{"id":3677358,"web_url":"http://patchwork.ozlabs.org/comment/3677358/","msgid":"<9d68b944-bd65-495b-b69c-e0d6758f15ee@linux.ibm.com>","list_archive_url":null,"date":"2026-04-14T18:45:54","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":73785,"url":"http://patchwork.ozlabs.org/api/people/73785/","name":"Farhan Ali","email":"alifm@linux.ibm.com"},"content":"On 4/14/2026 10:41 AM, Alex Williamson wrote:\n> On Tue, 14 Apr 2026 10:13:22 -0700\n> Farhan Ali wrote:\n>> On 4/14/2026 7:12 AM, Alex Williamson wrote:\n>>> On Mon, 13 Apr 2026 16:40:49 -0700\n>>> Farhan Ali wrote:\n>>>> On 4/13/2026 3:57 PM, Alex Williamson wrote:\n>>>>> On Mon, 13 Apr 2026 14:06:06 -0700\n>>>>> Farhan Ali wrote:\n>>>>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n>>>>>> index 5de618a3a5ee..2980ca39dd38 100644\n>>>>>> --- a/include/uapi/linux/vfio.h\n>>>>>> +++ b/include/uapi/linux/vfio.h\n>>>>>> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n>>>>>> */\n>>>>>> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n>>>>>> \n>>>>>> +/**\n>>>>>> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n>>>>>> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n>>>>>> + * involves platform firmware and notification to operating system is done\n>>>>>> + * by architecture specific mechanism. Exposing this information to\n>>>>>> + * userspace allows it to take appropriate actions to handle an\n>>>>>> + * error on the device. The pending_errors provide any additional errors\n>>>>>> + * pending for the device, and userspace should read until zero. A value of\n>>>>>> + * 0 for pending_errors and pec would indicate no pending errors that need\n>>>>>> + * to be handled.\n>>>>>> + */\n>>>>>> +\n>>>>>> +struct vfio_device_feature_zpci_err {\n>>>>>> +\t__u8 version;\n>>>>>> +\t__u8 pending_errors;\n>>>>>> +\t__u16 pec;\n>>>>>> +};\n>>>>> I assume .version is for compatibility, but we don't define a strategy\n>>>>> for using it or specify what the version should be for this table. It\n>>>>> doesn't seem like there's actually an value-add to having it.\n>>>> Its possible we may need to extend this structure in the future if we\n>>>> want to report more information to userspace. I at least want the\n>>>> flexibility to do so. We had some discussion around this [1] in an\n>>>> earlier version. I was trying to follow similar versioning pattern we\n>>>> had around vfio-pci/zdev structures.\n>>> IMHO, the version field is a dead end towards achieving this,\n>>> especially if we don't specify from the onset the expected version\n>>> value or the compatibility semantics. All that's going to happen is\n>>> that some userspace will hard code that it understands version 1\n>>> because that's what's currently reported and matches the struct defined\n>>> here, and you can never ever report anything other than version 1\n>>> without breaking that user. At that point you need to come up with\n>>> some other means for the user to opt-in to a new version, whether it's\n>>> triggered by another feature (as we did with the PRECOPY_INFOv2 above\n>>> this), or we reimplement the whole v2 feature.\n>> My understanding was based on how we version some of the capability\n>> structures for zdev (in include/uapi/linux/vfio_zdev.h). If we wanted to\n>> provide more information to userspace in the future, what would be\n>> preferred approach? Do we need to explicitly define a v2 feature? I am\n>> open to suggestions on this.\n>>\n>> If we need to define v2 explicitly in the future, then yes I agree we\n>> can simplify it to return only the PEC code (or an error code otherwise).\n> Maybe I'm reading too much into it, but it sounds like you already have\n> plans to expand this.\n>\n> The existing zdev structures seem to rely on the version field in the\n> capability header and maybe you've gotten away with bumping the version\n> without breaking userspace, but it's fragile. AFAICT, the ioctls do not\n> define a versioning strategy where vN+1 only adds fields to vN, so all\n> it takes is one outspoken userspace tool that hard codes its\n> compatibility to a specific version to become a problem for further\n> updates.\n>\n> Likewise this feature doesn't define a versioning policy for userspace\n> to follow. I'm sure there are other examples within vfio that are\n> problematic, but let's try not to create more.\n>\n> If you want to use a version, then also define what the version is and\n> what the compatibility policy is for future versions. A flags field is\n> another option that we've used extensively in vfio. The version field\n> might be better for incremental expansion of the structure, while flags\n> can address specific fields more directly, ex. a reserved field being\n> redefined. Thanks,\n>\n> Alex\n\nJust wanted to understand and clarify if we can associate multiple \nfields with a feature flag? I think in that case flags would be better \nhere and given its also something that is widely used in vfio. I am just \ntrying to figure out the best way we can extend this without a lot of \ncode churn in the future.\n\nI appreciate the feedback and discussion on this.\n\nThanks\n\nFarhan","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=LQpUY1gs;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52518-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"LQpUY1gs\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.158.5","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwCxt5vHNz1y2d\n\tfor ; Wed, 15 Apr 2026 04:49:54 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 45B913029743\n\tfor ; Tue, 14 Apr 2026 18:46:05 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CC69C202997;\n\tTue, 14 Apr 2026 18:46:04 +0000 (UTC)","from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n [148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 4941A16A956;\n\tTue, 14 Apr 2026 18:46:03 +0000 (UTC)","from pps.filterd (m0356516.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63EEEHpb1859874;\n\tTue, 14 Apr 2026 18:45:56 GMT","from ppma11.dal12v.mail.ibm.com\n (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89pcdxg-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 18:45:56 +0000 (GMT)","from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1])\n\tby ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63EHjFFx025831;\n\tTue, 14 Apr 2026 18:45:55 GMT","from smtprelay05.dal12v.mail.ibm.com ([172.16.1.7])\n\tby ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4dg3b1ju11-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 18:45:55 +0000","from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com\n [10.241.53.100])\n\tby smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63EIjsOj32375360\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tTue, 14 Apr 2026 18:45:55 GMT","from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id DF4C258057;\n\tTue, 14 Apr 2026 18:45:54 +0000 (GMT)","from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 35A3E58058;\n\tTue, 14 Apr 2026 18:45:54 +0000 (GMT)","from [9.61.240.138] (unknown [9.61.240.138])\n\tby smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP;\n\tTue, 14 Apr 2026 18:45:54 +0000 (GMT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776192364; cv=none;\n b=KcrQetnJCYHvu3YIKP1y5SHIiLDtTt5KIRHD+scJLlhEUtsl9e1lZEUnJcx1h3pdshgSBSfTz4c+69UBkXtAN73vOwqy5/cJfiu74XF2MxCLEjz5uByH1kSSupxnKG2C389z8RsUlpIDtDpCwPYOlOuChQlZ+FywxqxG53EcCds=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776192364; c=relaxed/simple;\n\tbh=4BVLYJNCB08LxpFtuxxwJ6fNFl8wv4GUHgOEmwq7+Ns=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=D5HfTpGwSZ9IaGXuM//J4cR9NpEHfRllqJBNkir+NDbj/FXxVTspsuKnN9QHO9NuehIz3hB7gUv07mlTSunjt/dRGqnFH/+rZVVxF+DPpGfwD1FbBc19x5WLMvcCgW6OzYIVBc25GeGQKy7QxHu45rTBOma5Akxu0cCpQ7f0v/k=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=LQpUY1gs; arc=none smtp.client-ip=148.163.158.5","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=pp1; bh=pU/Lmt\n\tNGfbrSzTl3fxBiZbfR12td7Tos12b+70Z29EY=; b=LQpUY1gs5gmkHjO2Q1NwBT\n\trDyYn08rWcY0uZKbKSSUjAvhtpZzJ8X+OogqUo/5nlqdB/W7uCKuP29cCKoRR/2s\n\tUOOgwt/oXOZIf1N/c10YwCfl2F5pO4x7eemTORGZeqYp9fjQ3i2FoHu5TD8oUQ29\n\t6Hl3MF61J5N3VbsYZWJsWqYt8JT/oUeCP3bDX05sQzhteCRpxyvU1cQiZsoW1NMl\n\t0fVWrp99XpVzx7qERnX3HI2y/ZCG9WQ7g3TRSxYaZ1Av9jll3W4tEURbk+ftURn/\n\tZ1WDKyLXPcUFdP2Z8AiwHq0zd3RZjK1NfRlo50NMu/mMm81LAAtRijuJOZdUWP3g\n\t==","Message-ID":"<9d68b944-bd65-495b-b69c-e0d6758f15ee@linux.ibm.com>","Date":"Tue, 14 Apr 2026 11:45:54 -0700","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","To":"Alex Williamson ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, schnelle@linux.ibm.com,\n mjrosato@linux.ibm.com","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n <20260413210608.2912-6-alifm@linux.ibm.com>\n <20260413165758.0f87312b@shazbot.org>\n \n <20260414081238.23e2cecc@shazbot.org>\n <5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>\n <20260414114132.31481b48@shazbot.org>","Content-Language":"en-US","From":"Farhan Ali ","In-Reply-To":"<20260414114132.31481b48@shazbot.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","X-Proofpoint-GUID":"6yF0ZApbGCOMcO6lu5aPliNWH2KYs_n9","X-Proofpoint-ORIG-GUID":"6yF0ZApbGCOMcO6lu5aPliNWH2KYs_n9","X-Authority-Analysis":"v=2.4 cv=WbE8rUhX c=1 sm=1 tr=0 ts=69de8b64 cx=c_pps\n a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=VnNF1IyMAAAA:8\n a=g5-iASi6csL-DJVLufsA:9 a=QEXdDO2ut3YA:10","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE0MDE3MSBTYWx0ZWRfX91s2XLUgY+FR\n 3oNusot9TSkXQzrIttRr5w36U8nA1QRjOqo2CFUd/J9KjkCsDWIsH2b9hxW93IPh7jaLsl6XpGK\n abI0sD/NABngR6bnmZVaSH/XiIytUCozT1SrnexScipNgKM6g2z2fzqk7KodCgqOSqx2jx0bV/t\n 9KIhasUXRQPEbzlvIZI7nqbA8HNLJak12kMifnxnoqj7k6mezWA0ue4IXk8hNppdRmKvneyctmC\n 835hwSqUw6/2tqUyTOXP+M89inQ69+mMrM5wFhLGQi8oLZGwhkqAI6WS96422G2AgenDrGFCx8F\n WiMlVfeCpROlqpKZpsWl+Vu4s3BabKXceSYWX/0E+/44AQq0IIHEYwJSwWvPCmV9DkW5IYg61I9\n p+AQpwhdMXsX6ue4dvAoa5vshJtRmO8U2hKTFYv1eM01GtnUhUqXDMpOT15S259RJD8l4tPXE7G\n vI/WMr/+IunUwioJnJA==","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-14_03,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n suspectscore=0 bulkscore=0 priorityscore=1501 spamscore=0 clxscore=1015\n phishscore=0 impostorscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140171"}},{"id":3677375,"web_url":"http://patchwork.ozlabs.org/comment/3677375/","msgid":"","list_archive_url":null,"date":"2026-04-14T19:43:19","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":78856,"url":"http://patchwork.ozlabs.org/api/people/78856/","name":"Niklas Schnelle","email":"schnelle@linux.ibm.com"},"content":"On Tue, 2026-04-14 at 11:45 -0700, Farhan Ali wrote:\n> On 4/14/2026 10:41 AM, Alex Williamson wrote:\n> > On Tue, 14 Apr 2026 10:13:22 -0700\n> > Farhan Ali wrote:\n> > > On 4/14/2026 7:12 AM, Alex Williamson wrote:\n> > > > On Mon, 13 Apr 2026 16:40:49 -0700\n> > > > Farhan Ali wrote:\n> > > > > On 4/13/2026 3:57 PM, Alex Williamson wrote:\n> > > > > > On Mon, 13 Apr 2026 14:06:06 -0700\n> > > > > > Farhan Ali wrote:\n> > > > > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> > > > > > > index 5de618a3a5ee..2980ca39dd38 100644\n> > > > > > > --- a/include/uapi/linux/vfio.h\n> > > > > > > +++ b/include/uapi/linux/vfio.h\n> > > > > > > @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n> > > > > > > */\n> > > > > > > #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n> > > > > > > \n> > > > > > > +/**\n> > > > > > > + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n> > > > > > > + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n> > > > > > > + * involves platform firmware and notification to operating system is done\n> > > > > > > + * by architecture specific mechanism. Exposing this information to\n> > > > > > > + * userspace allows it to take appropriate actions to handle an\n> > > > > > > + * error on the device. The pending_errors provide any additional errors\n> > > > > > > + * pending for the device, and userspace should read until zero. A value of\n> > > > > > > + * 0 for pending_errors and pec would indicate no pending errors that need\n> > > > > > > + * to be handled.\n> > > > > > > + */\n> > > > > > > +\n> > > > > > > +struct vfio_device_feature_zpci_err {\n> > > > > > > +\t__u8 version;\n> > > > > > > +\t__u8 pending_errors;\n> > > > > > > +\t__u16 pec;\n> > > > > > > +};\n> > > > > > I assume .version is for compatibility, but we don't define a strategy\n> > > > > > for using it or specify what the version should be for this table. It\n> > > > > > doesn't seem like there's actually an value-add to having it.\n> > > > > Its possible we may need to extend this structure in the future if we\n> > > > > want to report more information to userspace. I at least want the\n> > > > > flexibility to do so. We had some discussion around this [1] in an\n> > > > > earlier version. I was trying to follow similar versioning pattern we\n> > > > > had around vfio-pci/zdev structures.\n> > > > IMHO, the version field is a dead end towards achieving this,\n> > > > especially if we don't specify from the onset the expected version\n> > > > value or the compatibility semantics. All that's going to happen is\n> > > > that some userspace will hard code that it understands version 1\n> > > > because that's what's currently reported and matches the struct defined\n> > > > here, and you can never ever report anything other than version 1\n> > > > without breaking that user. At that point you need to come up with\n> > > > some other means for the user to opt-in to a new version, whether it's\n> > > > triggered by another feature (as we did with the PRECOPY_INFOv2 above\n> > > > this), or we reimplement the whole v2 feature.\n> > > My understanding was based on how we version some of the capability\n> > > structures for zdev (in include/uapi/linux/vfio_zdev.h). If we wanted to\n> > > provide more information to userspace in the future, what would be\n> > > preferred approach? Do we need to explicitly define a v2 feature? I am\n> > > open to suggestions on this.\n> > > \n> > > If we need to define v2 explicitly in the future, then yes I agree we\n> > > can simplify it to return only the PEC code (or an error code otherwise).\n> > Maybe I'm reading too much into it, but it sounds like you already have\n> > plans to expand this.\n> > \n> > The existing zdev structures seem to rely on the version field in the\n> > capability header and maybe you've gotten away with bumping the version\n> > without breaking userspace, but it's fragile. AFAICT, the ioctls do not\n> > define a versioning strategy where vN+1 only adds fields to vN, so all\n> > it takes is one outspoken userspace tool that hard codes its\n> > compatibility to a specific version to become a problem for further\n> > updates.\n> > \n> > Likewise this feature doesn't define a versioning policy for userspace\n> > to follow. I'm sure there are other examples within vfio that are\n> > problematic, but let's try not to create more.\n> > \n> > If you want to use a version, then also define what the version is and\n> > what the compatibility policy is for future versions. A flags field is\n> > another option that we've used extensively in vfio. The version field\n> > might be better for incremental expansion of the structure, while flags\n> > can address specific fields more directly, ex. a reserved field being\n> > redefined. Thanks,\n> > \n> > Alex\n> \n> Just wanted to understand and clarify if we can associate multiple \n> fields with a feature flag? I think in that case flags would be better \n> here and given its also something that is widely used in vfio. I am just \n> trying to figure out the best way we can extend this without a lot of \n> code churn in the future.\n> \n> I appreciate the feedback and discussion on this.\n> \n> Thanks\n> \n> Farhan\n\nHere is an idea. I think we even discussed this internally at some\npoint. How about we just use the architected CCDF Error Event (i.e.\nbasically struct zpci_ccdf_err with possible uAPI type adjustments) as\nthe data user-space reads. The bit definitions of it are already part\nof the architecture and it has provisions for extensibility based on\ns390 architecture principles which have worked quite well for forward\ncompatibility. If we additionally make it possible to query its length\nas kind of a version it could even grow. I think this would also work\nwell with the idea of returning an error on read if there are no more\nerror events and user-space reading again and again until it sees the\nerror. I agree with Alex that this seems much easier to get right than\na pending_errs count. As a bonus we can immediately expose all the\nerror event information Linux currently uses. That said, I would opt to\nsetting the struct fields by copying field by field explicitly and\nleaving reserved fields 0 such that we don't pass-through any bits a\nfuture platform may add without having a defined field in Linux.\nThoughts?\n\nThanks,\nNiklas","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=q2OYomj7;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-52520-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"q2OYomj7\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.156.1","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwF9335XKz1xtJ\n\tfor ; Wed, 15 Apr 2026 05:44:39 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 6D2263012BDC\n\tfor ; Tue, 14 Apr 2026 19:44:36 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 9B7BE2F0C74;\n\tTue, 14 Apr 2026 19:44:33 +0000 (UTC)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n [148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id EE1C32874FB;\n\tTue, 14 Apr 2026 19:44:31 +0000 (UTC)","from pps.filterd (m0356517.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63EEG9RD1833140;\n\tTue, 14 Apr 2026 19:44:24 GMT","from ppma13.dal12v.mail.ibm.com\n (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89rctnn-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 19:44:24 +0000 (GMT)","from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1])\n\tby ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63EHosRe025621;\n\tTue, 14 Apr 2026 19:44:23 GMT","from smtprelay03.dal12v.mail.ibm.com ([172.16.1.5])\n\tby ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4dg2ujk3aw-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 19:44:23 +0000","from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com\n [10.39.53.228])\n\tby smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63EJiM0533751806\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tTue, 14 Apr 2026 19:44:22 GMT","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 51F0558055;\n\tTue, 14 Apr 2026 19:44:22 +0000 (GMT)","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 428495804B;\n\tTue, 14 Apr 2026 19:44:20 +0000 (GMT)","from [9.111.15.149] (unknown [9.111.15.149])\n\tby smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP;\n\tTue, 14 Apr 2026 19:44:20 +0000 (GMT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776195873; cv=none;\n b=sckZJDpPg6XLnChKOcx5khVHyWTViiLHSOLIpyottYaT3nUwwOlgkRS7wjxDY9I5izAn0llQZ9AczSsedgTrdPiQdtqnui5wH3CAIk7W5j+5XZGwIMfQWvrLo3GagDs9bA05f1vuSvWbNT8s6m35ohtuvFff0XbFJ45FHVKkNF8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776195873; c=relaxed/simple;\n\tbh=4AuX3WinXAZ8gnhEaqxrBi8ElhjmL+FYzgS9/BvOJbE=;\n\th=Message-ID:Subject:From:To:Cc:In-Reply-To:References:Content-Type:\n\t Date:MIME-Version;\n b=Q7e5b2/DdAJiTcPYYkIjWD1dtVKe7cIQ5XlOVOc1g4cT41RY/jCH3b3BPYOtg49/H6x1acl4ZOHjl8z/hX0zenjlmRGJf+msB4pPYFSkjTOLUCgbdNIXM63pwmMfHH+fWohLDnkpX3a7dRfEmqG7q6r1qEyRHKA9oUKOdig5bzc=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=q2OYomj7; arc=none smtp.client-ip=148.163.156.1","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=pp1; bh=8psXap\n\t+o5EbNwrFZ3NxzMeUWMAVCSTurqs9Idz1VPfE=; b=q2OYomj7YIUGseLr5h4alB\n\tEslP72PFY1M/ka0Zrrw09L6m58kEY+JvO8aDS+9FeDr510ZH7QQCtHz1xpYyczDv\n\tUP3leDh365SNNMjmQxWsocNwiWjRAB3D0OvH/6WBSM0DAegeBjpz5tyHT089F3Y/\n\tVNae92LzIFofSzqk0u4xaEawVgi8MSnrdfY1+5DkHoGjK5X0Xq36zrwkT+S4gaOt\n\tbiuZY377hg1o9Sd+uqoe2eI5t/FtcO99ynk+PfEwKZCHyScleNisA9NJjGxITiny\n\tXpXgcnRPjiUvRLODrojCAFNJQLLLZCpY4lo+rCTHhVkWQDHR84axUT9ufpV1o3zw\n\t==","Message-ID":"","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","From":"Niklas Schnelle ","To":"Farhan Ali , Alex Williamson ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, mjrosato@linux.ibm.com","In-Reply-To":"<9d68b944-bd65-495b-b69c-e0d6758f15ee@linux.ibm.com>","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n\t <20260413210608.2912-6-alifm@linux.ibm.com>\n\t <20260413165758.0f87312b@shazbot.org>\n\t \n\t <20260414081238.23e2cecc@shazbot.org>\n\t <5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>\n\t <20260414114132.31481b48@shazbot.org>\n\t <9d68b944-bd65-495b-b69c-e0d6758f15ee@linux.ibm.com>","Autocrypt":"addr=schnelle@linux.ibm.com; prefer-encrypt=mutual;\n keydata=mQINBGHm3M8BEAC+MIQkfoPIAKdjjk84OSQ8erd2OICj98+GdhMQpIjHXn/RJdCZLa58k\n /ay5x0xIHkWzx1JJOm4Lki7WEzRbYDexQEJP0xUia0U+4Yg7PJL4Dg/W4Ho28dRBROoJjgJSLSHwc\n 3/1pjpNlSaX/qg3ZM8+/EiSGc7uEPklLYu3gRGxcWV/944HdUyLcnjrZwCn2+gg9ncVJjsimS0ro/\n 2wU2RPE4ju6NMBn5Go26sAj1owdYQQv9t0d71CmZS9Bh+2+cLjC7HvyTHKFxVGOznUL+j1a45VrVS\n XQ+nhTVjvgvXR84z10bOvLiwxJZ/00pwNi7uCdSYnZFLQ4S/JGMs4lhOiCGJhJ/9FR7JVw/1t1G9a\n UlqVp23AXwzbcoV2fxyE/CsVpHcyOWGDahGLcH7QeitN6cjltf9ymw2spBzpRnfFn80nVxgSYVG1d\n w75ksBAuQ/3e+oTQk4GAa2ShoNVsvR9GYn7rnsDN5pVILDhdPO3J2PGIXa5ipQnvwb3EHvPXyzakY\n tK50fBUPKk3XnkRwRYEbbPEB7YT+ccF/HioCryqDPWUivXF8qf6Jw5T1mhwukUV1i+QyJzJxGPh19\n /N2/GK7/yS5wrt0Lwxzevc5g+jX8RyjzywOZGHTVu9KIQiG8Pqx33UxZvykjaqTMjo7kaAdGEkrHZ\n dVHqoPZwhCsgQARAQABtChOaWtsYXMgU2NobmVsbGUgPHNjaG5lbGxlQGxpbnV4LmlibS5jb20+iQ\n JXBBMBCABBAhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAhkBFiEEnbAAstJ1IDCl9y3cr+Q/Fej\n CYJAFAmmAWs8FCQl6sYAACgkQr+Q/FejCYJAn2g//UKzlXOgizdk0wudLooRbGzDo23ktGSPK5Oj9\n 9o5z6v4Jz5+qOHo5835683cqkMLM9//udA1ZcKV88LVwyfmoHChPW24cWBmOEy7RJOWCR4WeEINaO\n pZUGF5YOx7oKTkPs511ky2FR0Heg35754pgTuTMEpYzRXr5pNMPS8mHXcXSARFPDPaCF+uBJ9BafO\n L7XbpSwKRttePsWAlPHbSbloeDApBfHUhcF/pbuM9GNs+c/8V9NK+SwwqNK214t7jaSq9k+19/hfE\n jvU45nbiYQM4VqGCelxVFRWol93JnwPFp/JaMgxgV1VYFH9Ijtgh+qNVVBqO8bbTjioFKy1bHdprN\n 9GyPLDxoaI/lBg+5CwKewzazUjFd0xaqZbTXSgNK4ev/IuNI3qZV8tpvZZWwIgZU1K0Bhplt8Sku+\n O9Yl2H54erq9zuzwXjqBJtoW0+MaKbe+1gZ/v2/AVE2VeQMugPUWDg+2bpJaApRkeA4xQ9XfeW6Bp\n It7xYrwwbVhQtWRC0sRh+QNlU9HI28wPSnLWn7HFBeWupaIrxSp4IEL3eHUn8xv4aA8lpdNsHXD/X\n vqOSUwy5jlTPTlemvwaC9mNHagNdVXng8C6+hxiDLhZ6xH2P4qNHTKmjW61NsdF6Y/HfWP+lmbi8/\n 474UNCltDt/fP01ajqogfWZKFymoH0O0KU5pa2xhcyBTY2huZWxsZSA8bmlrbGFzLnNjaG5lbGxlQ\n GlibS5jb20+iQJUBBMBCAA+AhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEnbAAstJ1IDCl9y\n 3cr+Q/FejCYJAFAmmAWusFCQl6sYAACgkQr+Q/FejCYJAtIw//WmQW/Z+SLdfrlDH5J2bvixzFNnO\n TOvp8uM8vcNZsxZwPXem4AeCXHayCqipxpa0iXWufEIvdMxkBxWvvM//V+rTUgQnJe6nhDxfLGklx\n 5Mb2H+K/ndS73ElCuA30MPYq7mHr8i3gEmi2ZFX1W47JecJ8hno/DQxhHRG7bd+GFsiKCbsjLWXNq\n s/VaAK9uyOTQx7m6/2nR8L+Mvl1BrRXwkj7Qp0qxfQSd4r+IVNBzNFOcrGagBqsyHrN7Is7IICktH\n 9VFl/G8P+hfviHQLnlxw9ltzpM1Dy6N1+BM3kbqD59gX+L6wqiLJI42eh+SHCiy35FvD3AFlYx4jZ\n MWE6qIgFnbwcL1kvcA7nnwfr3ZizCYPm8e334xXxslXBoRGsvjXSbAeAyZo2dvJXffNHdcDdUbJSl\n CfOixNGGKiQvs00X9ekfq9WmmRFvmYHu/m3lg1OXnMjFFIO41O51ZdhbEYJiqZEki7jA8Hd9xuWwQ\n nFDHhacU3xxivZ4BKQGQc+4XZ3yp/q6+7ux9prepRy/LeRyoaAmE67oxEsAgj+qyA3Tfy5nRTDdRQ\n E//gpaIt9H1VEx+68dRWHroxBQeozpnFPi25AlX3k4/EtVZjcItPWgE9iru1qT4DH3BBrz7Kd1zUw\n NnQC77zDJyZD2WUj1E+5bftO0aeE+7HZXj3tM/ea0K05pa2xhcyBTY2huZWxsZSA8bmlrbGFzLnNj\n aG5lbGxlQGdtYWlsLmNvbT6JAlQEEwEIAD4CGwEFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQSds\n ACy0nUgMKX3Ldyv5D8V6MJgkAUCaYBa6wUJCXqxgAAKCRCv5D8V6MJgkF/TEACOY2kL4NGFIbWeM5\n TUhatxqe8c3RT6jvNjq32CkvaK/cSZzBkS0smddyOzxt2WnsvMgkr9cM7P+CevoMwhT3e0lgQbqBD\n /vXZJjWKddC+iKXeqWkjMVcgCOsWNZ7PWEzRUT5X1AEFq2zzxQAQ/bCWEYNqIbHN4b6G1Wk+2Y598\n +KypZ3FS0bwiItnPQOWzOOqJCGxDxaEUuXFx4ah8HtVdtIev8jPS/5uzQO9iG2vZQUWeMEYZtfMHW\n sbFWqo2A3lxB+KPzNIYFhul4Lyx1CwvKUAGSHOx7FZuc2xI5DYt/Wdh2QyKFYr7xVzv3uwJjeS1+3\n 6gvyB7DJaQuY+PziNPv4GPr5wy0cRkJ6Ps15fgC6y6wNwoNdNXKlwiuclIsBzJKa7A0pZMIfpCpIJ\n bEHP7oy3drBRAhIrBx7Lx1lyqqodDqc+ok5IQ5WcKG/TOrH732mTmJX6fxYTiCVxcU4WLJSNZbrZ/\n pjF0AWXs7E+onAkQy6RLg/XU1iiU5QdMvug+fTA6TpPSUMdujWtGWUt3/4nC+69AVc8tXtRQTZ7gP\n t7uIcQFwPqUuJGS26vl0w/6dIABQAyU9acvE3adCZra+/PBKFZi/yxT1WgV1T2mexKSWwQgLcR57J\n Yp5oWnQRgi/S6fAoskIWkp9UVcfAQPY0p45NwO5cZR9/g06JZmyrQhTmlrbGFzIFNjaG5lbGxlIDx\n uaWtzQGtlcm5lbC5vcmc+iQJUBBMBCAA+AhsBBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEnbAA\n stJ1IDCl9y3cr+Q/FejCYJAFAmmAWusFCQl6sYAACgkQr+Q/FejCYJAz4A/9F+dMhzu7YonagL4qh\n WDz5IpRD4vzYKOBZ+qwYp1ugJz1BIUppN9i68HKoS4ARfgP97Sv9GpOy9g7L0lymH2MPF8hRPK0Yn\n 7DKIkeu/r28YWEoWfoVm5reC+gpxMgmxBz4JScE4f6xfa7+Nw0bbTDl+nxftJD7lf/dTiruNJsXph\n HQnZ5wPXmxeH6XVJikfpyrGe8iJZALbtHtjlx6Omu7NvRGikenB8trrWS5W0F60ZdbqH1HdmDDcrZ\n pDq6LtAARHK5tGRm0SK6sZpKe3nULFeeCt7T/edk2FC6KVh4sL1jw1kyceX4DjiMffqYBPrhK5gz5\n cDIixLBF9C6Wt1ObvuDBrIQf1/3q6EZrUrUuf6qtaXDMuC6cSlShm47qaPEvVYh67O9JZQ7vzvaea\n UI74DJUb8Pjnz7mTOmMOzsS1gUhCue4n2YSSM6ythioCGb/3bgMGTpuer3JhvZG5s5uKD9yyj8s8x\n 35qJkCFfjmjVx9s3vSUS48X+cUpYcMispErKzFu7C0YgKoxvJ4XTfXlDBiMFMPYcN67hsb2jeYHVJ\n wzE+fIZiDx9JLh1oQW2krwjweisE+3glOaKXZKi0fBtkxyH41iemLtLNYZRJopv6ykdl3hiI+Nh+a\n 3FZJPTo/OpqchMm8XIeDxC4NFFiPMpyLeYzIxO7eZpiGrAjVTE=","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Date":"Tue, 14 Apr 2026 21:43:19 +0200","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Evolution 3.58.3 (3.58.3-1.fc43) ","X-TM-AS-GCONF":"00","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE0MDE4MCBTYWx0ZWRfX8UGdny3Pgktc\n V6aV5N+UqZQpiG6Rgs2oZDJnh4hph6f1Oq7TNTfsI/BEESNwjOhHJARKy44pw5ZnDXO/8lfy3dK\n F6SxOJwGm587M0i1Z9eu8l54d4hhd/uUHv2zso0uR0aTqVv8o2AvsJdKGNso1nxEHmut9wg01Se\n S3FshUeILuIr6sw1u1zeo8vs7wwIZg/Q5KrJKIDeL5LavkQdqxV6y/yfTrOln25a8p2VXD47Ot1\n QukoQZRJUTdc5cTH6rhazlN8AQiH5j56jxnLUuYEtfkBPMS5DNrwfTbRgjzV2ZSg403ITzByk+y\n HPsY10V4a3YqXu6+3J0pbSEfvVw4hgvX0Fg276/Da2EUIP+dVocB8fLRGE22CQM0ajra7OQ9DkY\n BC45xu9B3QzkwRektHOGBxvROY++E5IYYgvz6z7csx6zUMnIid5bd7npECSPHLKGjLX6t6rZQo7\n vkE2nQvze0vNFVWILBA==","X-Proofpoint-ORIG-GUID":"Rm3hmD32Nt2jAuArtUpQkXsKxvIQc4HT","X-Proofpoint-GUID":"Rm3hmD32Nt2jAuArtUpQkXsKxvIQc4HT","X-Authority-Analysis":"v=2.4 cv=fYidDUQF c=1 sm=1 tr=0 ts=69de9918 cx=c_pps\n a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=VnNF1IyMAAAA:8\n a=wNQRYjWzGRkv4led_PgA:9 a=QEXdDO2ut3YA:10","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-14_04,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n adultscore=0 impostorscore=0 clxscore=1015 malwarescore=0 phishscore=0\n bulkscore=0 priorityscore=1501 spamscore=0 suspectscore=0 lowpriorityscore=0\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140180"}},{"id":3677405,"web_url":"http://patchwork.ozlabs.org/comment/3677405/","msgid":"<34f59b3b-dc28-4fd3-b2d6-d34bc4fd297c@linux.ibm.com>","list_archive_url":null,"date":"2026-04-14T21:06:31","subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":73785,"url":"http://patchwork.ozlabs.org/api/people/73785/","name":"Farhan Ali","email":"alifm@linux.ibm.com"},"content":"On 4/14/2026 12:43 PM, Niklas Schnelle wrote:\n> On Tue, 2026-04-14 at 11:45 -0700, Farhan Ali wrote:\n>> On 4/14/2026 10:41 AM, Alex Williamson wrote:\n>>> On Tue, 14 Apr 2026 10:13:22 -0700\n>>> Farhan Ali wrote:\n>>>> On 4/14/2026 7:12 AM, Alex Williamson wrote:\n>>>>> On Mon, 13 Apr 2026 16:40:49 -0700\n>>>>> Farhan Ali wrote:\n>>>>>> On 4/13/2026 3:57 PM, Alex Williamson wrote:\n>>>>>>> On Mon, 13 Apr 2026 14:06:06 -0700\n>>>>>>> Farhan Ali wrote:\n>>>>>>>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n>>>>>>>> index 5de618a3a5ee..2980ca39dd38 100644\n>>>>>>>> --- a/include/uapi/linux/vfio.h\n>>>>>>>> +++ b/include/uapi/linux/vfio.h\n>>>>>>>> @@ -1534,6 +1534,26 @@ struct vfio_device_feature_dma_buf {\n>>>>>>>> */\n>>>>>>>> #define VFIO_DEVICE_FEATURE_MIG_PRECOPY_INFOv2 12\n>>>>>>>> \n>>>>>>>> +/**\n>>>>>>>> + * VFIO_DEVICE_FEATURE_ZPCI_ERROR feature provides PCI error information to\n>>>>>>>> + * userspace for vfio-pci devices on s390x. On s390x, PCI error recovery\n>>>>>>>> + * involves platform firmware and notification to operating system is done\n>>>>>>>> + * by architecture specific mechanism. Exposing this information to\n>>>>>>>> + * userspace allows it to take appropriate actions to handle an\n>>>>>>>> + * error on the device. The pending_errors provide any additional errors\n>>>>>>>> + * pending for the device, and userspace should read until zero. A value of\n>>>>>>>> + * 0 for pending_errors and pec would indicate no pending errors that need\n>>>>>>>> + * to be handled.\n>>>>>>>> + */\n>>>>>>>> +\n>>>>>>>> +struct vfio_device_feature_zpci_err {\n>>>>>>>> +\t__u8 version;\n>>>>>>>> +\t__u8 pending_errors;\n>>>>>>>> +\t__u16 pec;\n>>>>>>>> +};\n>>>>>>> I assume .version is for compatibility, but we don't define a strategy\n>>>>>>> for using it or specify what the version should be for this table. It\n>>>>>>> doesn't seem like there's actually an value-add to having it.\n>>>>>> Its possible we may need to extend this structure in the future if we\n>>>>>> want to report more information to userspace. I at least want the\n>>>>>> flexibility to do so. We had some discussion around this [1] in an\n>>>>>> earlier version. I was trying to follow similar versioning pattern we\n>>>>>> had around vfio-pci/zdev structures.\n>>>>> IMHO, the version field is a dead end towards achieving this,\n>>>>> especially if we don't specify from the onset the expected version\n>>>>> value or the compatibility semantics. All that's going to happen is\n>>>>> that some userspace will hard code that it understands version 1\n>>>>> because that's what's currently reported and matches the struct defined\n>>>>> here, and you can never ever report anything other than version 1\n>>>>> without breaking that user. At that point you need to come up with\n>>>>> some other means for the user to opt-in to a new version, whether it's\n>>>>> triggered by another feature (as we did with the PRECOPY_INFOv2 above\n>>>>> this), or we reimplement the whole v2 feature.\n>>>> My understanding was based on how we version some of the capability\n>>>> structures for zdev (in include/uapi/linux/vfio_zdev.h). If we wanted to\n>>>> provide more information to userspace in the future, what would be\n>>>> preferred approach? Do we need to explicitly define a v2 feature? I am\n>>>> open to suggestions on this.\n>>>>\n>>>> If we need to define v2 explicitly in the future, then yes I agree we\n>>>> can simplify it to return only the PEC code (or an error code otherwise).\n>>> Maybe I'm reading too much into it, but it sounds like you already have\n>>> plans to expand this.\n>>>\n>>> The existing zdev structures seem to rely on the version field in the\n>>> capability header and maybe you've gotten away with bumping the version\n>>> without breaking userspace, but it's fragile. AFAICT, the ioctls do not\n>>> define a versioning strategy where vN+1 only adds fields to vN, so all\n>>> it takes is one outspoken userspace tool that hard codes its\n>>> compatibility to a specific version to become a problem for further\n>>> updates.\n>>>\n>>> Likewise this feature doesn't define a versioning policy for userspace\n>>> to follow. I'm sure there are other examples within vfio that are\n>>> problematic, but let's try not to create more.\n>>>\n>>> If you want to use a version, then also define what the version is and\n>>> what the compatibility policy is for future versions. A flags field is\n>>> another option that we've used extensively in vfio. The version field\n>>> might be better for incremental expansion of the structure, while flags\n>>> can address specific fields more directly, ex. a reserved field being\n>>> redefined. Thanks,\n>>>\n>>> Alex\n>> Just wanted to understand and clarify if we can associate multiple\n>> fields with a feature flag? I think in that case flags would be better\n>> here and given its also something that is widely used in vfio. I am just\n>> trying to figure out the best way we can extend this without a lot of\n>> code churn in the future.\n>>\n>> I appreciate the feedback and discussion on this.\n>>\n>> Thanks\n>>\n>> Farhan\n> Here is an idea. I think we even discussed this internally at some\n> point. How about we just use the architected CCDF Error Event (i.e.\n> basically struct zpci_ccdf_err with possible uAPI type adjustments) as\n> the data user-space reads. The bit definitions of it are already part\n> of the architecture and it has provisions for extensibility based on\n> s390 architecture principles which have worked quite well for forward\n> compatibility. If we additionally make it possible to query its length\n> as kind of a version it could even grow. I think this would also work\n> well with the idea of returning an error on read if there are no more\n> error events and user-space reading again and again until it sees the\n> error. I agree with Alex that this seems much easier to get right than\n> a pending_errs count. As a bonus we can immediately expose all the\n> error event information Linux currently uses. That said, I would opt to\n> setting the struct fields by copying field by field explicitly and\n> leaving reserved fields 0 such that we don't pass-through any bits a\n> future platform may add without having a defined field in Linux.\n> Thoughts?\n>\n> Thanks,\n> Niklas\n\nMy concern with exposing the entire struct zpci_ccdf_err was it could be \nerror prone trying to keep the struct and vfio uAPI struct in sync. Just \nthinking out loud, to query the length we would need a different vfio \ndevice feature bit? But if it makes for a better uAPI, I can make the \nchange. Thanks\n\nFarhan","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256\n header.s=pp1 header.b=nJDVft1G;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-52521-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=\"nJDVft1G\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=148.163.158.5","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.ibm.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwGzp26gFz1y2d\n\tfor ; Wed, 15 Apr 2026 07:06:46 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 42DD8302579B\n\tfor ; Tue, 14 Apr 2026 21:06:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CBEF2373BF8;\n\tTue, 14 Apr 2026 21:06:41 +0000 (UTC)","from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n [148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 190A9375F69;\n\tTue, 14 Apr 2026 21:06:39 +0000 (UTC)","from pps.filterd (m0353725.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id\n 63EEgwZ11734239;\n\tTue, 14 Apr 2026 21:06:34 GMT","from ppma22.wdc07v.mail.ibm.com\n (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92])\n\tby mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4dh89m4ven-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 21:06:33 +0000 (GMT)","from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1])\n\tby ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id\n 63EHGKa0031099;\n\tTue, 14 Apr 2026 21:06:33 GMT","from smtprelay07.wdc07v.mail.ibm.com ([172.16.1.74])\n\tby ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4dg10ybmxe-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);\n\tTue, 14 Apr 2026 21:06:33 +0000","from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com\n [10.39.53.228])\n\tby smtprelay07.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n 63EL6VM528246540\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);\n\tTue, 14 Apr 2026 21:06:32 GMT","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id E128658063;\n\tTue, 14 Apr 2026 21:06:31 +0000 (GMT)","from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id CE02B5804B;\n\tTue, 14 Apr 2026 21:06:30 +0000 (GMT)","from [9.61.247.90] (unknown [9.61.247.90])\n\tby smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP;\n\tTue, 14 Apr 2026 21:06:30 +0000 (GMT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776200801; cv=none;\n b=u3YJPfmbijyAoo9NA4KJf1YKFucG2dGNWHaBqAf+qem8GkNWk2/cMiFP87fQOLZzoWnqPfWDNhVLhiptgats9dLdyXVGAOWT0crn7s9+OVT0liYrai6DISfdcn1sBAql2uLO+prYrm7+ag2Ym+Es2yr3hvcRlqm9wU3vbEPqijo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776200801; c=relaxed/simple;\n\tbh=0eqcVAJWSX/W0HjnY8IjzDHeLzD4g5oztWf/V5RI6UA=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=WFDC4b4S0QEX4mRD0kPwFh0s6jA2meWwroAfPJrYzhGvYQpFYeOJT1F3cytR+FATXbs1D3w21Gix2x1LRKftGbF8yy+MK9rDtxSJiBqdjCW6Hi2PWDaTpfkk1wZGqwPevC4oL7snqliWPJ/7pMVdRJvLgGcHaWfOlYWYQvtL++s=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.ibm.com;\n spf=pass smtp.mailfrom=linux.ibm.com;\n dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com\n header.b=nJDVft1G; arc=none smtp.client-ip=148.163.158.5","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc\n\t:content-transfer-encoding:content-type:date:from:in-reply-to\n\t:message-id:mime-version:references:subject:to; s=pp1; bh=xqostE\n\tCAIlXCSPHLFQl/SCSIqNIXiec7UAF0E3+iqu4=; b=nJDVft1GbpCrWiqQyiZRPv\n\tO9uwuFoWgUHdegCWQ5YKH0zofocmPrZL+i4QD/CgGwpRT6MTijR4Uo+XVnOsj0Sj\n\tmYhiJmaYUZ2taW1iXdJxPu50SToi4g8IVAID5YGhHD8autYylT+kC+8/CSB82VWn\n\t60JR0K9CpW7h+iDDKqY5HMYJTZ0gdK+RQgPCM80pZwDI4/Ien0FF8/kNUZjou1Wu\n\t48J6W9srtrj0b1ijtoAp1Qw75Dt9usYPZ8iIL3kM37VhbXwxyEfwMJuqQi9N+4VW\n\tiHY0xDJgD2kF/o2LHlgPD/jDlfaNaCPs3SCJGgat56JP0DHlfBuYgyvfGSCEUA5A\n\t==","Message-ID":"<34f59b3b-dc28-4fd3-b2d6-d34bc4fd297c@linux.ibm.com>","Date":"Tue, 14 Apr 2026 14:06:31 -0700","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v13 5/7] vfio-pci/zdev: Add a device feature for error\n information","To":"Niklas Schnelle ,\n Alex Williamson ","Cc":"linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-pci@vger.kernel.org, helgaas@kernel.org, lukas@wunner.de,\n clg@redhat.com, kbusch@kernel.org, mjrosato@linux.ibm.com","References":"<20260413210608.2912-1-alifm@linux.ibm.com>\n <20260413210608.2912-6-alifm@linux.ibm.com>\n <20260413165758.0f87312b@shazbot.org>\n \n <20260414081238.23e2cecc@shazbot.org>\n <5f26af4c-9584-4c70-9702-0a3bcd0c4ad1@linux.ibm.com>\n <20260414114132.31481b48@shazbot.org>\n <9d68b944-bd65-495b-b69c-e0d6758f15ee@linux.ibm.com>\n ","Content-Language":"en-US","From":"Farhan Ali ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","X-Authority-Analysis":"v=2.4 cv=I/dVgtgg c=1 sm=1 tr=0 ts=69deac59 cx=c_pps\n a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17\n a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22\n a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=VnNF1IyMAAAA:8\n a=1b2_H57lPKfI2HTGgoQA:9 a=QEXdDO2ut3YA:10","X-Proofpoint-GUID":"j9kVDP58I3JX55hzCEeCHV7Nrb1Gc6Xc","X-Proofpoint-Spam-Details-Enc":"AW1haW4tMjYwNDE0MDE5NCBTYWx0ZWRfX9aTcOc8LhNJR\n ZasRoLujPS+rQWH+DE4zOdg7r/kGzVeAjWkTs3uuxPc/ImdVveE9vwvGhUZVY2R9PyjZhHi89PA\n oY6m+GsULGMKRxT1y8ZIYNzX7oy2azcFMOJnXL0vOM7OQBTM7SY6v6uyimPjq0J8cBJ+/JLa0Hx\n HwklhSLXYooaVjfjUPno3gToU21jfoddm3uOUdUkxEOfJf39gF6q1JH8lTF2IL7PNIfePSagajL\n mQ9eah5rRAVqNn6uM+R/OFXneYXFkkiB12vrhJx2XglijltdZH4eS1PGGUj0j8vwEBhlstk6s0k\n nvhIKSh9cpv8HM1ZqgoYpimtylw81gUyZxTMtZGGri0L18CBkS59juHJqd03Xxpy0Whrnphn94X\n e7fh1FjWxFIYWhmU21u7/qUbQyq7TyLcOc+SD7GtZGDunmPsqjeQ57F033x7C1tQFNuSvz1d8kt\n A3e26gz18/AoZLgcfQA==","X-Proofpoint-ORIG-GUID":"j9kVDP58I3JX55hzCEeCHV7Nrb1Gc6Xc","X-Proofpoint-Virus-Version":"vendor=baseguard\n engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49\n definitions=2026-04-14_04,2026-04-13_04,2025-10-01_01","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n malwarescore=0 bulkscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0\n suspectscore=0 impostorscore=0 phishscore=0 spamscore=0 priorityscore=1501\n classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0\n reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140194"}}]