From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olaf Hering <olaf@aepfle.de>
Subject: Re: [PATCH v8 3/3] tools/libxc: use superpages during
 restore of HVM guest
Date: Fri, 1 Sep 2017 10:37:36 +0200
Message-ID: <20170901083736.GC21663@aepfle.de>
References: <20170901082149.6355-1-olaf@aepfle.de>
 <20170901082149.6355-4-olaf@aepfle.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7949317023488535314=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20170901082149.6355-4-olaf@aepfle.de>
List-Unsubscribe: <https://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <https://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: xen-devel@lists.xen.org, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
List-Id: xen-devel@lists.xenproject.org


--===============7949317023488535314==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi"
Content-Disposition: inline


--zbGR4y+acU1DwHSi
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

On Fri, Sep 01, Olaf Hering wrote:

> +static int x86_hvm_populate_pfns(struct xc_sr_context *ctx, unsigned count,

> +            /*
> +             * If this next pfn is within another 1GB superpage it is required
> +             * to scan the entire previous superpage because there might be
> +             * holes between max_pfn and the end of the superpage.
> +             */
> +            if ( idx1G_prev != idx1G )
> +            {
> +                order = SUPERPAGE_1GB_SHIFT;
> +                max_pfn = (((max_pfn >> order) + 1) << order) - 1;
> +            }
> +            if ( x86_hvm_punch_hole(ctx, max_pfn) == false )


And thinking about this part: with this variant it is still possible
that Over-allocation happens. If the previous pfn was within a 2MB
range, and this pfn is in another 2MB range, then the hole after max_pfn
would not be covered. This part needs an 'else' with
SUPERPAGE_2MB_SHIFT.

This "reset to max" may trigger a bug in xc_sr_test_and_clear_bit(). It
has to check the size of the bitmap, just as xc_sr_test_bit() does.

Olaf

--zbGR4y+acU1DwHSi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWakcTAAKCRBdQqD6ppg2
fiFjAJ0Q8c+G/eV+ZLKDhRibiKy13kaYDgCfeZvhTqkdgq/dIu6HtxBUv4Yo80Y=
=jIgS
-----END PGP SIGNATURE-----

--zbGR4y+acU1DwHSi--


--===============7949317023488535314==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

--===============7949317023488535314==--