From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiH8C-0005aB-AC for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:49:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YiH87-0007oY-9a for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:49:04 -0400 Received: from e28smtp07.in.ibm.com ([122.248.162.7]:39234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YiH86-0007ip-KN for qemu-devel@nongnu.org; Wed, 15 Apr 2015 02:48:59 -0400 Received: from /spool/local by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Apr 2015 12:18:52 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 43C323940048 for ; Wed, 15 Apr 2015 12:18:51 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t3F6moaQ41353370 for ; Wed, 15 Apr 2015 12:18:50 +0530 Received: from d28av02.in.ibm.com (localhost [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t3F6S9ff014435 for ; Wed, 15 Apr 2015 11:58:10 +0530 From: Hong Bo Li Date: Wed, 15 Apr 2015 14:48:40 +0800 Message-Id: <1429080521-8008-1-git-send-email-lihbbj@linux.vnet.ibm.com> Subject: [Qemu-devel] [PATCH v1 0/1] s390 pci infrastucture modeling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, agraf@suse.de, mst@redhat.com This patch extends the current s390 pci implementation to provide more flexibility in configuration of s390 specific device handling. For this we had to introduce a new facility (and bus) to hold devices representing information actually provided by s390 firmware and I/O configuration. For each vfio pci device, I create a zpci device to store s390 specific informations. And attach all of these special zpci devices to the s390 facility bus. A zpci device references the corresponding PCI device via device id. Compare to the old implementation, I moved the actual hotplug/unplug codes to s390 pci device hot plug function. Then in the pcihost hotplug function, we don't need to do anything special. In the pcihost unplug function, we need to unplug the corresponding zpci device. The new design allows to define multiple host bridges, each host bridge could hold 32 zpci devices at most. The topology for this implementation could be: dev: s390-pcihost, id "" bus: pci.0 type PCI dev: vfio-pci, id "vpci1" host = "0000:00:00.0" ...... dev: vfio-pci, id "vpci2" host = "0001:00:00.0" ...... dev: s390-pci-facility, id "" bus: s390-pci-fac-bus.0 type s390-pci-fac-bus dev: zpci, id "zpci1" fid = 1 (0x1) uid = 2 (0x2) pci_id = "vpci1" dev: zpci, id "zpci2" fid = 6 (0x6) uid = 7 (0x7) pci_id = "vpci2" To make the review easier, I keep all of the old names, such as S390PCIBusDevice to name a zpci device. I will make a cleanup patch later to change these names to a more suitable name. Hong Bo Li (1): s390 pci infrastructure modeling hw/s390x/s390-pci-bus.c | 317 +++++++++++++++++++++++++++++++++------------ hw/s390x/s390-pci-bus.h | 48 ++++++- hw/s390x/s390-pci-inst.c | 4 +- hw/s390x/s390-virtio-ccw.c | 4 +- 4 files changed, 285 insertions(+), 88 deletions(-) -- 1.9.3