On Wed, 12 Nov 2014 21:30:20 +0100 Laszlo Ersek <lersek at 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 at 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 at 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
