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. Petr T
