Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756763AbdD1PZg (ORCPT ); Fri, 28 Apr 2017 11:25:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57617 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756482AbdD1PZ3 (ORCPT ); Fri, 28 Apr 2017 11:25:29 -0400 Date: Fri, 28 Apr 2017 17:25:20 +0200 (CEST) From: Sebastian Ott X-X-Sender: sebott@schleppi.fritz.box To: Joerg Roedel cc: Gerald Schaefer , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support In-Reply-To: <20170428145513.GH1332@8bytes.org> References: <1493306905-32334-1-git-send-email-joro@8bytes.org> <20170427201018.70c8be5a@thinkpad> <20170427210325.GE1332@8bytes.org> <20170428144634.7950c8cf@thinkpad> <20170428145513.GH1332@8bytes.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) Organization: =?ISO-8859-15?Q?=22IBM_Deutschland_Research_&_Development_GmbH_=2F_Vorsitzende_des_Aufsichtsrats=3A_Martina_Koederitz_Gesch=E4ftsf=FChrung=3A_Dirk_Wittkopp_Sitz_der_Gesellschaft=3A_B=F6blingen_=2F_Registergericht?= =?ISO-8859-15?Q?=3A_Amtsgericht_Stuttgart=2C_HRB_243294=22?= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-TM-AS-GCONF: 00 x-cbid: 17042815-0016-0000-0000-0000048C33A2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17042815-0017-0000-0000-00002772F390 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-28_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704280208 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1440 Lines: 36 On Fri, 28 Apr 2017, Joerg Roedel wrote: > On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > > On Thu, 27 Apr 2017 23:03:25 +0200 > > Joerg Roedel wrote: > > > > > > Well, there is a separate zpci_dev for each pci_dev on s390, > > > > and each of those has its own separate dma-table (thus not shared). > > > > > > Is that true for all functions of a PCIe card, so does every function of > > > a device has its own zpci_dev structure and thus its own DMA-table? > > > > Yes, clp_add_pci_device() is called for every function, which in turn calls > > zpci_create_device() with a freshly allocated zdev. zpci_enable_device() > > then sets up a new DMA address space for each function. > > That sounds special :) So will every function of a single device end up > as a seperate device on a seperate root-bus? Yes. That's true even for multi-function and SRIOV. > > > My assumption came from the fact that the zpci_dev is read from > > > pci_dev->sysdata, which is propagated there from the pci_bridge > > > through the pci_root_bus structures. > > > > The zdev gets there via zpci_create_device() -> zpci_scan_bus() -> > > pci_scan_root_bus(), which is done for every single function. > > > > Not sure if I understand this right, but it looks like we set up a new PCI > > bus for each function. > > Yeah, it sounds like this. Maybe Sebastian can confirm that? Yes. Confirmed. Regards, Sebastian