On Monday 18 January 2010 19:32:14 Avi Kivity wrote: > On 01/18/2010 11:32 AM, Sheng Yang wrote: > > On Sunday 17 January 2010 20:34:23 Avi Kivity wrote: > >> On 01/15/2010 10:44 AM, Sheng Yang wrote: > >>> Currently we only have handle_invalid_guest_state() reported emulation > >>> failure... > >> > >> This is intentional - instead of spamming dmesg, we exit with an > >> internal error. Modern qemu-kvm will halt and allow the user to inspect > >> the guest with the built-in disassembler. > > > > I think keep it there still useful for some users. And we have the same > > report in handle_invalid_guest_state(), and we even have "emulation > > failure, check dmesg for details" in QEmu when handling > > KVM_INTERNAL_ERROR_EMULATION. > > > > I think add one line here is the easiest way to keep consistence, and is > > handy. > > Another way to keep consistency is to remove emulation failure reporting > in handle_invalid_guest_state() :) OK, I would remove it... > There are two problems with the kernel failure report. First, it > doesn't report enough data - registers, surrounding instructions, etc. > that are needed to explain what is going on. Second, it can flood > dmesg, which is a pretty bad thing to do. When you talking about "built-in disassembler", do you talking about "memsave/objdump" or some other more convenient way for this? And maybe we can let QEmu do some dump of the assembler code? (kvm_show_code()) > I have a patch somewhere that adds instruction emulation bytes (both > successful and failed) to ftrace. That may be useful, perhaps. It would surely help. :) -- regards Yang, Sheng -- 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
