From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYZA-0006dx-Ev for qemu-devel@nongnu.org; Tue, 19 Jan 2016 10:51:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLYZ4-0000zc-3f for qemu-devel@nongnu.org; Tue, 19 Jan 2016 10:51:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLYZ3-0000yh-RR for qemu-devel@nongnu.org; Tue, 19 Jan 2016 10:51:26 -0500 Message-ID: <1453218682.32741.218.camel@redhat.com> From: Alex Williamson Date: Tue, 19 Jan 2016 08:51:22 -0700 In-Reply-To: <569E103C.4060103@neat.it> References: <20160118142819.GF26923@neat.it> <346807287.9165899.1453130191659.JavaMail.zimbra@redhat.com> <1453135313.32741.92.camel@redhat.com> <569E103C.4060103@neat.it> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] hw/misc: slavepci_passthru driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Francesco Zuliani , =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau Cc: qemu-devel@nongnu.org On Tue, 2016-01-19 at 11:30 +0100, Francesco Zuliani wrote: > Hi Alex, >=20 >=20 > On 01/18/2016 05:41 PM, Alex Williamson wrote: > > On Mon, 2016-01-18 at 10:16 -0500, Marc-Andr=C3=A9 Lureau wrote: > > > Hi > > >=20 > > > ----- Original Message ----- > > > > Hi there, > > > >=20 > > > > I'd like to submit this new pci driver ( hw/misc )for inclusion, > > > > if you think it could be useful to other as well as ourself. > > > >=20 > > > > The driver "worked for our needs" BUT we haven't done extensive > > > > testing and this is our first attempt to submit a patch so I kind= ly > > > > ask for extra-forgiveness . > > > >=20 > > > > The "slavepci_passthru" driver is useful in the scenario describe= d > > > > below to implement a simplified passthru when the host CPU does n= ot > > > > support IOMMU and one is interested only in pci target-mode (slav= e > > > > devices). > > > Let's CC Alex, who worked on the most recent framework for somethin= g related to that (VFIO). > > >=20 > > > > Embedded system cpu (e.g. Atom, AMD G-Series) often lack the VT-d > > > > extensions (IOMMU) needed to be able to pass-thru pci peripherals= to > > > > the guest machine (i.e. the pci pass-thru feature cannot be used)= . > > > >=20 > > > > If one is only interested in using the pci board as a pci-target > > > > (slave device), this driver mmap(s) the host-pci-bars into the gu= est > > > > within a virtual pci-device. > > What exactly do you mean by pci-target/slave device?=C2=A0=C2=A0Does = this mean > > that the device is not DMA capable, ie. cannot enable BusMaster? >=20 > Yes, exactly. Our approach=C2=A0=C2=A0can be used ONLY if one is NOT in= terested in=C2=A0 > DMA-Capability (i.e. it is not possible to enable BusMaster) > > > > This is useful in our case for debugging via qemu gsbserver facil= ity > > > > (i.e. '-s' option in qemu) a system running barebone-executable . > > > >=20 > > > > Currently the driver assumes the custom pci card has four 32-bit = bars > > > > to be mapped (in current patch this is mandatory) > > > >=20 > > > > HowTo: > > > > To use the new driver one shall: > > > > - define two environment variables for assigning proper VID and D= ID to > > > > =C2=A0=C2=A0=C2=A0associate to the guest pci card > > > > - give the host pci bar address to map in the guest. > > > >=20 > > > > Example Usage: > > > >=20 > > > > Let us suppose that we have in the host a slave pci device with t= he > > > > following 4 bars (i.e. output of lspci -v -s YOUR-CARD | grep Mem= ory) > > > > =C2=A0=C2=A0=C2=A0Memory at db800000 (32-bit, non-prefetchable) [= size=3D4K] > > > > =C2=A0=C2=A0=C2=A0Memory at db900000 (32-bit, non-prefetchable) [= size=3D8K] > > > > =C2=A0=C2=A0=C2=A0Memory at dba00000 (32-bit, non-prefetchable) [= size=3D4K] > > > > =C2=A0=C2=A0=C2=A0Memory at dbb00000 (32-bit, non-prefetchable) [= size=3D4K] > > > >=20 > > > > We can map these bars in a guest-pci with VID=3D0xe33e DID=3D0x00= 0a using > > > >=20 > > > > SLAVEPASSTHRU_VID=3D"0xe33e" SLAVEPASSTHRU_DID=3D"0xa" qemu-syste= m-x86_64 \ > > > > =C2=A0=C2=A0=C2=A0YOUR-SET-OF-FLAGS \ > > > > =C2=A0=C2=A0=C2=A0-device > > > > =C2=A0=C2=A0=C2=A0slavepassthru,size1=3D4096,baseaddr1=3D0xdb9000= 00,size2=3D8192,baseaddr2=3D0xdba00000,size3=3D4096,baseaddr3=3D0xdbd0000= 0,size4=3D4096,baseaddr4=3D0xdbe00000 > > > >=20 > > > > Please note that if your device has less than four bars you can g= ive > > > > the same size and baseaddress to the unused bars. > > Those are some pretty serious usage restrictions and using /dev/mem i= s > > really not practical.=C2=A0=C2=A0The resource files in pci-sysfs woul= d even be a > > better option. > our was a quick hack to fulfill our needs, the approach via sysfs is > of course the right one and we would implement it if this patch is of=C2= =A0 > interest. >=20 > > I didn't see how IO and MMIO BARs get enabled on the > > physical device or whether you support any kind of interrupt scheme. > In our case the IO space is not used. > The MMIO space is already enabled. >=20 > Our custom board does not have any interrupt and our quick hack > did not implement it. > > =C2=A0=C2=A0=C2=A0I > > had never really intended QEMU use of this, but you might want to > > consider vfio no-iommu mode: > >=20 > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit= /drivers/vfio/vfio.c?id=3D03a76b60f8ba27974e2d252bc555d2c103420e15 > >=20 > > Using this taints the kernel, but maybe that's nothing you mind if > > you're already letting QEMU access /dev/mem.=C2=A0=C2=A0The QEMU vfio= -pci driver > > would need to be modified to use the new device and of course it > > wouldn't have IOMMU translation capabilities.=C2=A0=C2=A0That means t= hat the > > BusMaster bit should protected and MSI/X capabilities should be hidde= n > > from the VM.=C2=A0=C2=A0It seems more flexible and featureful than wh= at you have > > here.=C2=A0=C2=A0Thanks, >=20 > I was not aware of this interesting patch, I will study it to see if > it fits our use case. >=20 > Just for information you mean "taint" in that "security" is broken, not > licensing issues, am I right? Yes, it's only tainting for security, the driver is part of the standard Linux kernel. =C2=A0There's really no way to guarantee that we c= an prevent the user from enabling BusMaster on a device capable of DMA, even if we trapped access to that config space bit, devices often have back doors to PCI config space, so it's best just to assume DMA is possible and mark the host kernel as vulnerable. =C2=A0Thanks, Alex