On Thu, Aug 04, 2016 at 10:41:16AM +0200, Laurent Vivier wrote:
>
>
> 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 monitor:
> >>
> >> (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 <lviv...@redhat.com>
> >> ---
> >> target-ppc/arch_dump.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >
> > 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.
>
> virtio-balloon doesn't work with 4K kernel.
>
> > 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.
>
> I agree with you but none of the other architectures probes for the page
> size.
>
> For instance ARM: |I cc: Drew to know how he has chosen the values]
>
> if (arm_feature(env, ARM_FEATURE_AARCH64)) {
> ...
> info->page_size = (1 << 16);
> ...
> } else {
> ...
> info->page_size = (1 << 12);
> ...
> }
>
info->page_size is used to determine the dumpfile's block size. The
block size needs to be at least the page size, but a multiple of page
size works fine too. As we can't probe for the currently used guest
page size, and a multiple of page size is fine, then using the guest's
maximum allowed page size is the best we can do.
Thanks,
drew
