From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCsT-0001DF-UT for qemu-devel@nongnu.org; Mon, 18 Jan 2016 11:42:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLCsO-0006rU-U6 for qemu-devel@nongnu.org; Mon, 18 Jan 2016 11:42:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLCsO-0006rK-ME for qemu-devel@nongnu.org; Mon, 18 Jan 2016 11:41:56 -0500 Message-ID: <1453135313.32741.92.camel@redhat.com> From: Alex Williamson Date: Mon, 18 Jan 2016 09:41:53 -0700 In-Reply-To: <346807287.9165899.1453130191659.JavaMail.zimbra@redhat.com> References: <20160118142819.GF26923@neat.it> <346807287.9165899.1453130191659.JavaMail.zimbra@redhat.com> 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: =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , Francesco Zuliani Cc: qemu-devel@nongnu.org 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 kindly > > ask for extra-forgiveness . > >=20 > > The "slavepci_passthru" driver is useful in the scenario described > > below to implement a simplified passthru when the host CPU does not > > support IOMMU and one is interested only in pci target-mode (slave > > devices). >=20 > Let's CC Alex, who worked on the most recent framework for something re= lated to that (VFIO). >=20 > >=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 guest > > within a virtual pci-device. What exactly do you mean by pci-target/slave device? =C2=A0Does this mean that the device is not DMA capable, ie. cannot enable BusMaster? > > This is useful in our case for debugging via qemu gsbserver facility > > (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 DID t= o > > =C2=A0 associate 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 the > > following 4 bars (i.e. output of lspci -v -s YOUR-CARD | grep Memory) > > =C2=A0 Memory at db800000 (32-bit, non-prefetchable) [size=3D4K] > > =C2=A0 Memory at db900000 (32-bit, non-prefetchable) [size=3D8K] > > =C2=A0 Memory at dba00000 (32-bit, non-prefetchable) [size=3D4K] > > =C2=A0 Memory at dbb00000 (32-bit, non-prefetchable) [size=3D4K] > >=20 > > We can map these bars in a guest-pci with VID=3D0xe33e DID=3D0x000a u= sing > >=20 > > SLAVEPASSTHRU_VID=3D"0xe33e" SLAVEPASSTHRU_DID=3D"0xa" qemu-system-x8= 6_64 \ > > =C2=A0 YOUR-SET-OF-FLAGS \ > > =C2=A0 -device > > =C2=A0 slavepassthru,size1=3D4096,baseaddr1=3D0xdb900000,size2=3D8192= ,baseaddr2=3D0xdba00000,size3=3D4096,baseaddr3=3D0xdbd00000,size4=3D4096,= baseaddr4=3D0xdbe00000 > >=20 > > Please note that if your device has less than four bars you can give > > the same size and baseaddress to the unused bars. Those are some pretty serious usage restrictions and using /dev/mem is really not practical. =C2=A0The resource files in pci-sysfs would even be= a better option. =C2=A0I didn't see how IO and MMIO BARs get enabled on the physical device or whether you support any kind of interrupt scheme. =C2=A0= I had never really intended QEMU use of this, but you might want to consider vfio no-iommu mode: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/dri= vers/vfio/vfio.c?id=3D03a76b60f8ba27974e2d252bc555d2c103420e15 Using this taints the kernel, but maybe that's nothing you mind if you're already letting QEMU access /dev/mem. =C2=A0The QEMU vfio-pci driv= er would need to be modified to use the new device and of course it wouldn't have IOMMU translation capabilities. =C2=A0That means that the BusMaster bit should protected and MSI/X capabilities should be hidden from the VM. =C2=A0It seems more flexible and featureful than what you ha= ve here. =C2=A0Thanks, Alex