Re: uniquely identifying KDUMP files that originate from QEMU

From: Petr Tesarik <ptesarik@suse.cz>
To: Laszlo Ersek <lersek@redhat.com>
Cc: wency@cn.fujitsu.com, tumanova@linux.vnet.ibm.com,
	kexec@lists.infradead.org, qiaonuohan@cn.fujitsu.com,
	qemu-devel@nongnu.org,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	kumagai-atsushi@mxc.nes.nec.co.jp, anderson@redhat.com,
	crash-utility@redhat.com
Subject: Re: uniquely identifying KDUMP files that originate from QEMU
Date: Wed, 12 Nov 2014 22:20:47 +0100	[thread overview]
Message-ID: <20141112222047.3b76a80d@hananiah.suse.cz> (raw)
In-Reply-To: <5463C35C.2000103@redhat.com>

On Wed, 12 Nov 2014 21:30:20 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> adding back a few CC's because this discussion is useful
> 
> On 11/12/14 19:43, Petr Tesarik wrote:
> > V Wed, 12 Nov 2014 15:50:32 +0100
> > Laszlo Ersek <lersek@redhat.com> napsáno:
> > 
> >> On 11/12/14 09:04, Petr Tesarik wrote:
> >>> On Wed, 12 Nov 2014 12:08:38 +0900 (JST)
> >>> HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> >>
> >>>> Anyway, phys_base is kernel information. To make it available for qemu
> >>>> side, there's need to prepare a mechanism for qemu to have any access
> >>>> to it.
> >>>
> >>> Yes. I wonder if you can have access without some sort of co-operation
> >>> from the guest kernel itself. I guess not.
> >>
> >> Propagating any kind of additional information from the guest kernel
> >> (which is unprivileged and potentially malicious) to the host-side qemu
> >> process (which is by definition more privileged, although still confined
> >> by various measures) is something we'd explicitly like to avoid.
> >>
> >> Think of it like this. I throw a physical box at you, running Linux,
> >> that has frozen in time. Can "crash" work with nothing else but the
> >> contents of the memory, and information about the CPUs?
> > 
> > If only you could save the _complete_ state of the CPU... For example
> > the content of CR3 would be quite useful.
> 
> (1) CR3 is already saved, in both the ELF and the kdump compressed formats.

Sweet. :-)

So, there's no need for any heuristics. Since CR3 gives the physical
address of the PML4 table, I can use it to translate __START_KERNEL_map
(0xffffffff80000000UL on all Linux kernels since introduction of
x86_64) to a physical address and compute phys_base from that.

In fact, QEMU could do the same if you can live with hardcoding a
Linux-kernel specific constant into the tool...

Petr T

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec