On Fri, Jul 11, 2008 at 1:53 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > Mohammed Gamal wrote: >> On Fri, Jul 11, 2008 at 12:22 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote: >>> Mohammed Gamal wrote: >>>> On Thu, Jul 10, 2008 at 11:02 PM, Anthony Liguori <[EMAIL PROTECTED]> >>>> wrote: >>>>> Mohammed Gamal wrote: >>>>>> On Thu, Jul 10, 2008 at 7:31 PM, Anthony Liguori <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>> >>>>>>> Mohammed Gamal wrote: >>>>>>> >>>>>>>> After updating my kvm-userspace tree to the latest git tree. I am no >>>>>>>> more able to run FreeDOS. The VM freezes after choosing any of the >>>>>>>> boot options. I am running both latest kvm.git and kvm-userspace.git >> >> <snip> >> >>>> After booting FreeDOS, there are a number of boot options with >>>> different memory extenders, after selecting any option the system >>>> freezes and I get [Stopped] in thr QEMU title bar. >>> "Stopped" - interesting. Seems like something causes QEMU to stop the >>> guest as if some breakpoint was injected. >>> >>> I just downloaded that image and gave it a try against vanilla kvm-70 >>> and my own tree which is augment with guest debugging related patches. >>> The former shows your observed behavior (Boot from CD, provide an empty >>> HD image -> press '1' + ENTER -> press '1' -> "Stopped"). The latter kvm >>> tree made QEMU leave with a #GP in the guest. That may point to a debug >>> register related issue, and that patch you identified just happen to >>> make it visible. However, will try to investigate. >>> >>> Jan >> >> I'm interested in seeing these patches. If your tree is hosted online, >> could you please provide me with its location so that I can merge it >> with mine. If not, where can I get them from? > > Find both attached. They are a rebase of the kernel side (subset) from > my earlier posted debug rework series. They apply against latest kvm > kernel git in this order: > > 1. kvm-new-guest-debug-interface-v2.patch > 2. kvm-x86-virtualize-debug-registers-v2.patch > > The first one makes no difference, but the second one changes the > behavior from reporting a breakpoint to userland to reporting an exception. >
Thanks for sending. > I haven't found enough time to dig into this yet, but my gut feeling so > far is that some x86 real mode emulation issue is biting us. Debug > registers are not involved, I've cross-checked with enhanced QEMU > supporting that feature - no invocation of related helper functions there. > I still think it might be an issue with debug exceptions. I did get a #GP after applying your patches. Analyizng the output I observed a few things: - rflags has TF, IF, DF, RF, and of course VM set and IOPL = 3. Do we handle interrupts while being aware that single-stepping takes a higher priority over all other external interrupts? May be some interrupt was injected while TF was set and we try to serve that interrupt first? If yes, would that cause a #GP? - The #GP pushed error code b . CIIW, but doesn't this mean it was caused by a #DB exception (bits EXT = 1, IDT = 1, with IDT vector 1 which is a debug exception) . Regards, Mohammed -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
