From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: PCI passthrough with stubdomain Date: Fri, 23 Sep 2016 10:48:14 +0200 Message-ID: <20160923084814.GS7339@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1496703889573452623==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: xen-devel Cc: HW42 List-Id: xen-devel@lists.xenproject.org --===============1496703889573452623== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bxyj5TNvuouCjAp1" Content-Disposition: inline --bxyj5TNvuouCjAp1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm still trying to get PCI passthrough working with stubdomain and without qemu in dom0 (even for just vfb/vkbd backends). How is this supposed to work? 1. Should xen-pcifront in the target domain be used (and consequently, should xen-pciback be set for it)? Currently xen-pciback is set for both stubdomain and target domain, which presents a race condition and xen-pciback refuses to setup one of them. (I have a patch for this, but not sure how it really should work) 1a. How does it look in case of qemu in dom0 (no stubdomain)? 2. What operations are done through stubdomain and what are handled directly by Xen (itself, or with help of IOMMU)? I'd guess config space accesses are done through device model. Anything else? 3. What changes (if any) are required in qemu-xen to have it working in stubdomain in regards to PCI passthrough? Should it just work (assuming Linux-based stubdomain with xen-pcifront driver)? PS If anyone interested, here are more details: https://github.com/QubesOS/qubes-issues/issues/1659 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --bxyj5TNvuouCjAp1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX5OxOAAoJENuP0xzK19csvfMH/2jRK1w7XOLyk1u7Az2RXevM RCkZSrqfqBnbcuP8W65GGMMONVCJbAROjc8ciTRJNXMllT7cr24bRxao05+Lxlhj ZryrJUwvyLJNAKdWUxjOqzdUkJjor3FT2SV6siuZv+F0TEGzSY+cRRWJgNRKp7Pg J+lLw8K1qqJP9SouWxU54f2/jmHkj+SAHfvLc8NTckHBEgfJY53Nonlq7wajs+Bp p4R62d+/9es+rWhKbol7Q269Hmef+mUOF+g1JF2VseILQOdlauYeZVjPY3RrGlVE w7zjnrBh/ysgi+vc1dPOiBeKQQgXbMHqTzj68YdJC8vWnb9A4KZ3UKC3RWdsIJY= =hScN -----END PGP SIGNATURE----- --bxyj5TNvuouCjAp1-- --===============1496703889573452623== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1496703889573452623==--