From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH v2 3/3] tools/libxc: use superpages during restore of HVM guest Date: Tue, 22 Aug 2017 17:53:25 +0200 Message-ID: <20170822155325.GA6372@aepfle.de> References: <20170817170133.30939-1-olaf@aepfle.de> <20170817170133.30939-4-olaf@aepfle.de> <20170822153116.xi6tcqumodcxmrfd@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3648718940575769913==" Return-path: In-Reply-To: <20170822153116.xi6tcqumodcxmrfd@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu Cc: Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============3648718940575769913== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, Wei Liu wrote: > On Thu, Aug 17, 2017 at 07:01:33PM +0200, Olaf Hering wrote: > > + /* No superpage in 1st 2MB due to VGA hole */ > > + xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_1g); > > + xc_sr_set_bit(0, &ctx->x86_hvm.restore.attempted_2m); > I don't quite get this. What about other holes such as MMIO? This just copies what meminit_hvm does. Is there a way to know where the MMIO hole is? Maybe I just missed the MMIO part. In the worst case I think a super page is allocated, which is later split into single pages. > One potential issue I can see with your algorithm is, if the stream of > page info contains pages from different super pages, the risk of going > over memory limit is high (hence failing the migration). >=20 > Is my concern unfounded? In my testing I have seen the case of over-allocation. Thats why I implemented the freeing of unpopulated parts. It would be nice to know how many pages are actually coming. I think this info is not available. On the other side, the first iteration sends the pfns linear. This is when the allocation actually happens. So the over-allocation will only trigger near the end, if a 1G range is allocated but only a few pages will be stored into this range. Olaf --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWZxTcgAKCRBdQqD6ppg2 fgVVAKCNa6YfnhHS34d3jVAeb0JJWSn/kQCghhme4JVmMXAeiYdgRn4PKhyoBXI= =9WPk -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- --===============3648718940575769913== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3648718940575769913==--