From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall" Date: Wed, 22 Jun 2016 15:03:35 +0200 Message-ID: <20160622130335.GA410@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8968738032881002966==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: xen-devel List-Id: xen-devel@lists.xenproject.org --===============8968738032881002966== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've finally found what was causing long standing issue of not working PCI passthrough for HVM domains with qemu in stubdomain (only - without the other one in dom0). It looks to be this patch: http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dcommitdiff;h=3Dc428c9f162895= cb3473fab26d23ffbf41a6f293d;hp=3Ddcccaf806a92eabb95929a67c344ac1e9ead6257 It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if the target domain is auto-translated), but xc_domain_getinfo fails with EPERM in stubdomain. What would be the best solution for this? Allowing xc_domain_getinfo =66rom stubdomain in xen/include/xsm/dummy.h? Currently it is uses policy XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have some combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly implementing the logic from that commit solely in libxl? --=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? --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXaoynAAoJENuP0xzK19csHH0H/22Rt4vCXDxMQlD3bdT4U8C4 vBeCtXDUyMtcR6inwWBV7MCjcBrSY00smGaeky1+LbkzCYRzX51+G8qWfXN76Uib BGh5WegTjVXYGEiKbW3yH9hzjOOK3FGC7n2rsTi/MBQ0C1CHgdpASQzMKx+1kHGr /osXw5ub7cjM/oNJsc9WPmIp3943f7ITUIflufXjM88zIM/ECl4Pnu7QNnwZMtTu WxTrlx6S0MAuV8kpl/NHWu88weFeoP095gP/To1kXMMeF2G46J7W3NRyS13u9E63 mLzEwWijaljtQ/A+70Jw+p1WX2G+dqfPYYuVkvczMyW9BrLbio43CXzbFUqe150= =Au3F -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- --===============8968738032881002966== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============8968738032881002966==--