From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Json config and stubdomain Date: Sat, 24 Sep 2016 12:42:45 +0200 Message-ID: <20160924104245.GT7339@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1412585233094821748==" 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 --===============1412585233094821748== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MzsmyedFbLQMXviL" Content-Disposition: inline --MzsmyedFbLQMXviL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Debugging stubdomain continuation... When stubdomain is started, it has no json config created. This results in multiple problems: - impossible to dynamically attach additional devices - starting a domain with more than one PCI device fails The second one is especially interesting because it look so much inconsistent: libxl__device_pci_add_xenstore when called for the first device, it immediately calls libxl__create_pci_backend and do not touch json config at all. But when called for the next device, it loads json config, adds the device there and save it. So it looks like the first PCI device will never be saved into json config (when added dynamically). In case of stubdomain, libxl__device_pci_add_xenstore is called during stubdomain startup, so defining two or more PCI devices means domain startup fail. So, the question is, whether json config should be created and properly maintained for stubdomain, or not created at all (assuming all the configuration is already handled in the target domain json config)? --=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? --MzsmyedFbLQMXviL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX5lilAAoJENuP0xzK19csKlkH/iv1mD8R6nTspMqXFCqEDhvU FikrQ+qsxP4f9yvG2LqkRUjn1zUz0oTxCsQilY0pnyEgregYM+vlfmP9DYkFCKDU VQxf6lquvJjbflfE+ujdSVMKgUI4tCuCXQzFyfagM+DW2clSbc4/B/eacuWMQ0RA QwcMZodtLlW8shFlxWzAb8tDv/wIB39PAQpEpDry4XWnMGBwciV0oqAv5zN8pfdJ SEf9dpyYCIC4qxw57d05xrdpZF1L+DVi0Vn1gha3+s8jz+MDg5vsTa/z25REgYEI MkVftwi5AAf9VMKvfzkOmVcrCuVjEImFn68bGJVTNOzmZpR82tXqRYZ98tuJ/RU= =rJGH -----END PGP SIGNATURE----- --MzsmyedFbLQMXviL-- --===============1412585233094821748== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1412585233094821748==--