From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVZqs-0000Ie-Ix for qemu-devel@nongnu.org; Fri, 05 Aug 2016 03:47:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVZqq-00012n-Hk for qemu-devel@nongnu.org; Fri, 05 Aug 2016 03:47:29 -0400 Date: Fri, 5 Aug 2016 17:49:20 +1000 From: David Gibson Message-ID: <20160805074920.GJ9189@voom.fritz.box> References: <1470254107-14842-1-git-send-email-lvivier@redhat.com> <20160804023800.GE9189@voom.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+9faIjRurCDpBc7U" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] ppc64: fix compressed dump with pseries kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: Alexander Graf , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Andrew Jones , Thomas Huth --+9faIjRurCDpBc7U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 04, 2016 at 10:41:16AM +0200, Laurent Vivier wrote: 1;4402;0c>=20 >=20 > On 04/08/2016 04:38, David Gibson wrote: > > On Wed, Aug 03, 2016 at 09:55:07PM +0200, Laurent Vivier wrote: > >> If we don't provide the page size in target-ppc:cpu_get_dump_info(), > >> the default one (TARGET_PAGE_SIZE, 4KB) is used to create > >> the compressed dump. It works fine with Macintosh, but not with > >> pseries as the kernel default page size is 64KB. > >> > >> Without this patch, if we generate a compressed dump in the QEMU monit= or: > >> > >> (qemu) dump-guest-memory -z qemu.dump > >> > >> This dump cannot be read by crash: > >> > >> # crash vmlinux qemu.dump > >> ... > >> WARNING: cannot translate vmemmap kernel virtual addresses: > >> commands requiring page structure contents will fail > >> ... > >> > >> Signed-off-by: Laurent Vivier > >> --- > >> target-ppc/arch_dump.c | 5 +++++ > >> 1 file changed, 5 insertions(+) > >=20 > > Urgh.. so, really the page size used by the guest kernel is a > > guest-side detail, and it's certainly possible to build a 4kiB page > > guest kernel, although 64kiB is the norm. >=20 > virtio-balloon doesn't work with 4K kernel. It doesn't? Balloon has rather a lot of flaws, but I didn't think that was one of them. > > This might be the best we can do, but it'd be nice if we could probe > > or otherwise avoid relying on this assumption about the guest kernel. >=20 > I agree with you but none of the other architectures probes for the page > size. Yeah :/ > For instance ARM: |I cc: Drew to know how he has chosen the values] >=20 > if (arm_feature(env, ARM_FEATURE_AARCH64)) { > ... > info->page_size =3D (1 << 16); > ... > } else { > ... > info->page_size =3D (1 << 12); > ... > } >=20 > In the kernel: >=20 > arch/arm64/include/asm/page.h: >=20 > #define PAGE_SHIFT CONFIG_ARM64_PAGE_SHIFT >=20 > arch/arm64/Kconfig: >=20 > config ARM64_PAGE_SHIFT > int > default 16 if ARM64_64K_PAGES > default 14 if ARM64_16K_PAGES > default 12 >=20 > choice > prompt "Page size" > default ARM64_4K_PAGES > help > Page size (translation granule) configuration. >=20 > config ARM64_4K_PAGES > bool "4KB" > help > This feature enables 4KB pages support. >=20 > config ARM64_16K_PAGES > bool "16KB" > help > The system will use 16KB pages support. AArch32 emulation > requires applications compiled with 16K (or a multiple of 16K) > aligned segments. >=20 > config ARM64_64K_PAGES > bool "64KB" > help > This feature enables 64KB pages support (4KB by default) > allowing only two levels of page tables and faster TLB > look-up. AArch32 emulation requires applications compiled > with 64K aligned segments. >=20 > endchoice >=20 > I think we can't rely on the CPU state or the memory content as they can > be corrupted. I guess. I don't know that we can really get what we want from there anyway, at least not without even more assumptions about the guest state than. Hrm. I guess I'm ok with the change, but I'd like the commit message updated to recognize that this is a compromise just designed to work with the most common guests. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --+9faIjRurCDpBc7U Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXpEUAAAoJEGw4ysog2bOS3OIP/3NcwGTqZafxnQdIcy8IhVLc MbHOuxk51B2EiJlzlPU6ljk98Iuk/kAdbK9t0fddwBleoh9cog9i+UtXtlGVSVy3 O3buHRNKrZYW8KF/wp9k08GMaQGWCE+/d6Qlz4momOuEVI4v9DfZ/H5DW1wCV57G ke1hyMCANQQ4tuxMEVtLuBl3NcGBttj9ttO6NgkXi6WTwIoVlQJWZe3fvcEkbh/+ X/GKrDPFcK6LDnloNBGp57K/hs7guN10NBk3rOISpcv8vQPgk0Bvu6cl4wSsBgX+ SDlK0/xBq7czKXgWEcDmeyyVoeyDBb9WcOA6Qe6XP4uwkiqOd3KRzqFRcjpe5SVj ApRV0Ng1GCm3xPk6wj4i+EPb//rizbH7FNvAppwq9orEoNoFR+u3H/BZdyHxcXXf ZTmSUQYaQrVNzR6qPhG0Q05kXTTfvFKzyvWhramAfS1reSElrYvsdmZz98kYqmjo Vgsc4ZVXowmKI/d+Tjgi35oiNiBll8vU5Hhp1Vfpk51egg3GBcYodoo8XSpyltY1 LRWKNlE6TAXSkyZqkCK8pZKP49I4hoHQ80Kb3rYKpfjYv6IMDLpZvsS8J/CANoow RDqbwafsJrxmXem3nO+InSFixLjC9OGNAuw5LwkY638Z7sdsCtV4mIEYPDByA4Bh kcUsslurRUmglImeGw2w =405j -----END PGP SIGNATURE----- --+9faIjRurCDpBc7U--