On Thu, Jan 12, 2012 at 03:59:59PM +0200, Avi Kivity wrote: > On 01/04/2012 05:03 AM, Isaku Yamahata wrote: > > Yes, it's quite doable in user space(qemu) with a kernel-enhancement. > > And it would be easy to convert a separated daemon process into a thread > > in qemu. > > > > I think it should be done out side of qemu process for some reasons. > > (I just repeat same discussion at the KVM-forum because no one remembers > > it) > > > > - ptrace (and its variant) > > Some people want to investigate guest ram on host (qemu stopped or lively). > > For example, enhance crash utility and it will attach qemu process and > > debug guest kernel. > > To debug the guest kernel you don't need to stop qemu itself. I agree > it's a problem for qemu debugging though. But you need to debug postcopy migration too with gdb or not? I don't see a big benefit in trying to prevent gdb to see really what is going on in the qemu image. > > - core dump > > qemu process may core-dump. > > As postmortem analysis, people want to investigate guest RAM. > > Again enhance crash utility and it will read the core file and analyze > > guest kernel. > > When creating core, the qemu process is already dead. > > Yes, strong point. > > > It precludes the above possibilities to handle fault in qemu process. > > I agree. In the receiving node if the memory is not there yet (and it isn't), not sure how you plan to get a clean core dump (like if live migration wasn't running) by preventing the kernel from dumping zeroes if qemu crashes during post copy migration. Surely it won't be the kernel crash handler completing the post migration, it won't even know where to write the data in memory. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
