From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: superpages lost after migration of HVM domU Date: Thu, 20 Apr 2017 17:35:23 +0200 Message-ID: <20170420153523.GG4645@aepfle.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0637335964925246159==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============0637335964925246159== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sw7tCqrGA+HQ0/zt" Content-Disposition: inline --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Andrew, with eab806a097b ("tools/libxc: x86 PV restore code") the only call of xc_domain_populate_physmap_exact was added to the new restore code. This call always sets order=0. The old migration code did consider superpages, the new one does not. What is the reason for not using superpages when populating a HVM domU? I supposed the first iteration would allocate all of the required memory for a domU, perhaps as superpages. ~ollowing iterations would just refill existing pages. Olaf --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWPjVOAAKCRBdQqD6ppg2 fvTrAJ4ue8U/XWCI8Ez1ubFZKWDA6Rky8ACg5EA584kNvFGszWWJIEjLiveVxlk= =T/+z -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt-- --===============0637335964925246159== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0637335964925246159==--