From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4676DC49ED7 for ; Thu, 19 Sep 2019 22:27:13 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 184FA20678 for ; Thu, 19 Sep 2019 22:27:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 184FA20678 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id B027ACCC; Thu, 19 Sep 2019 22:27:12 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 70946CC9 for ; Thu, 19 Sep 2019 22:27:11 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3F5E108 for ; Thu, 19 Sep 2019 22:27:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 016AA89AC7; Thu, 19 Sep 2019 22:27:10 +0000 (UTC) Received: from x1.home (ovpn-118-102.phx2.redhat.com [10.3.118.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id D856060BF1; Thu, 19 Sep 2019 22:27:08 +0000 (UTC) Date: Thu, 19 Sep 2019 16:27:08 -0600 From: Alex Williamson To: Matthew Rosato Subject: Re: [PATCH v4 3/4] vfio: zpci: defining the VFIO headers Message-ID: <20190919162708.07d4eec4@x1.home> In-Reply-To: <0a62aba7-578a-6875-da4d-13e8b145cf9b@linux.ibm.com> References: <1567815231-17940-1-git-send-email-mjrosato@linux.ibm.com> <1567815231-17940-4-git-send-email-mjrosato@linux.ibm.com> <20190919172009.71b1c246.cohuck@redhat.com> <0a62aba7-578a-6875-da4d-13e8b145cf9b@linux.ibm.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 19 Sep 2019 22:27:10 +0000 (UTC) Cc: gor@linux.ibm.com, linux-s390@vger.kernel.org, walling@linux.ibm.com, kvm@vger.kernel.org, sebott@linux.ibm.com, pmorel@linux.ibm.com, Cornelia Huck , heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, pasic@linux.ibm.com, borntraeger@de.ibm.com, iommu@lists.linux-foundation.org, robin.murphy@arm.com, gerald.schaefer@de.ibm.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org On Thu, 19 Sep 2019 16:55:57 -0400 Matthew Rosato wrote: > On 9/19/19 11:20 AM, Cornelia Huck wrote: > > On Fri, 6 Sep 2019 20:13:50 -0400 > > Matthew Rosato wrote: > > > >> From: Pierre Morel > >> > >> We define a new device region in vfio.h to be able to > >> get the ZPCI CLP information by reading this region from > >> userland. > >> > >> We create a new file, vfio_zdev.h to define the structure > >> of the new region we defined in vfio.h > >> > >> Signed-off-by: Pierre Morel > >> Signed-off-by: Matthew Rosato > >> --- > >> include/uapi/linux/vfio.h | 1 + > >> include/uapi/linux/vfio_zdev.h | 35 +++++++++++++++++++++++++++++++++++ > >> 2 files changed, 36 insertions(+) > >> create mode 100644 include/uapi/linux/vfio_zdev.h > >> > >> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > >> index 8f10748..8328c87 100644 > >> --- a/include/uapi/linux/vfio.h > >> +++ b/include/uapi/linux/vfio.h > >> @@ -371,6 +371,7 @@ struct vfio_region_gfx_edid { > >> * to do TLB invalidation on a GPU. > >> */ > >> #define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1) > >> +#define VFIO_REGION_SUBTYPE_ZDEV_CLP (2) > > > > Using a subtype is fine, but maybe add a comment what this is for? > > > > Fair point. Maybe something like "IBM ZDEV CLP is used to pass zPCI > device features to guest" And if you're going to use a PCI vendor ID subtype, maintain consistent naming, VFIO_REGION_SUBTYPE_IBM_ZPCI_CLP or something. Ideally there'd also be a reference to the struct provided through this region otherwise it's rather obscure to find by looking for the call to vfio_pci_register_dev_region() and ops defined for the region. I wouldn't be opposed to defining the region structure here too rather than a separate file, but I guess you're following the example set by ccw. > >> > >> /* > >> * The MSIX mappable capability informs that MSIX data of a BAR can be mmapped > >> diff --git a/include/uapi/linux/vfio_zdev.h b/include/uapi/linux/vfio_zdev.h > >> new file mode 100644 > >> index 0000000..55e0d6d > >> --- /dev/null > >> +++ b/include/uapi/linux/vfio_zdev.h > >> @@ -0,0 +1,35 @@ > >> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > >> +/* > >> + * Region definition for ZPCI devices > >> + * > >> + * Copyright IBM Corp. 2019 > >> + * > >> + * Author(s): Pierre Morel > >> + */ > >> + > >> +#ifndef _VFIO_ZDEV_H_ > >> +#define _VFIO_ZDEV_H_ > >> + > >> +#include > >> + > >> +/** > >> + * struct vfio_region_zpci_info - ZPCI information. > > > > Hm... probably should also get some more explanation. E.g. is that > > derived from a hardware structure? > > > > The structure itself is not mapped 1:1 to a hardware structure, but it > does serve as a collection of information that was derived from other > hardware structures. > > "Used for passing hardware feature information about a zpci device > between the host and guest" ? > > >> + * > >> + */ > >> +struct vfio_region_zpci_info { > >> + __u64 dasm; > >> + __u64 start_dma; > >> + __u64 end_dma; > >> + __u64 msi_addr; > >> + __u64 flags; > >> + __u16 pchid; > >> + __u16 mui; > >> + __u16 noi; > >> + __u16 maxstbl; > >> + __u8 version; > >> + __u8 gid; > >> +#define VFIO_PCI_ZDEV_FLAGS_REFRESH 1 > >> + __u8 util_str[]; > >> +} __packed; > >> + > >> +#endif I'm half tempted to suggest that this struct could be exposed directly through an info capability, the trouble is where. It would be somewhat awkward to pick an arbitrary BAR or config space region to expose this info. The VFIO_DEVICE_GET_INFO ioctl could include it, but we don't support capabilities on that return structure and I'm not sure it's worth implementing versus the solution here. Just a thought. Thanks, Alex _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu