From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPom0-00067f-KA for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:21:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPols-0005kT-SH for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:21:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52862 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPols-0005kL-Kw for qemu-devel@nongnu.org; Fri, 05 Sep 2014 04:21:28 -0400 Message-ID: <54097287.1000006@suse.de> Date: Fri, 05 Sep 2014 10:21:27 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140904105223.336503578@de.ibm.com> In-Reply-To: <20140904105223.336503578@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC][patch 0/6] pci pass-through support for qemu/KVM on s390 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: frank.blaschka@de.ibm.com, qemu-devel@nongnu.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org Cc: aik@ozlabs.ru, pbonzini@redhat.com, Alex Williamson On 04.09.14 12:52, frank.blaschka@de.ibm.com wrote: > This set of patches implements pci pass-through support for qemu/KVM on= s390. > PCI support on s390 is very different from other platforms. > Major differences are: >=20 > 1) all PCI operations are driven by special s390 instructions > 2) all s390 PCI instructions are privileged > 3) PCI config and memory spaces can not be mmap'ed That's ok, vfio abstracts config space anyway. > 4) no classic interrupts (INTX, MSI). The pci hw understands the concep= t > of requesting MSIX irqs but irqs are delivered as s390 adapter irqs. This is in line with other implementations. Interrupts go from device -> PHB -> PIC -> CPU (some times you can have another converter device in between) In your case, the PHB converts INTX and MSI interrupts to Adapter interrupts to go to the floating interrupt controller. Same thing as everyone else really. > 5) For DMA access there is always an IOMMU required. s390 pci implement= ation > does not support a complete memory to iommu mapping, dma mappings ar= e > created on request. Sounds great :). So I suppose we should implement a guest facing IOMMU? > 6) The OS does not get any informations about the physical layout > of the PCI bus. So how does it know whether different devices are behind the same IOMMU context? Or can we assume that every device has its own context? > 7) To take advantage of system z specific virtualization features > we need to access the SIE control block residing in the kernel KVM Pleas elaborate. > 8) To enable system z specific virtualization features we have to manip= ulate > the zpci device in kernel. Why? >=20 > For this reasons I decided to implement a kernel based approach similar > to x86 device assignment. There is a new qemu device (s390-pci) represe= nting a I fail to see the rationale and I definitely don't want to see anything even remotely similar to the legacy x86 device assignment on s390 ;). Can't we just enhance VFIO? Also, I think we'll get the cleanest model if we start off with an implementation that allows us to add emulated PCI devices to an s390x machine and only then follow on with physical ones. Alex