Mohammed Gamal wrote: > On Fri, Jul 11, 2008 at 1:53 PM, Jan Kiszka wrote: >> Mohammed Gamal wrote: >>> On Fri, Jul 11, 2008 at 12:22 AM, Jan Kiszka wrote: >>>> Mohammed Gamal wrote: >>>>> On Thu, Jul 10, 2008 at 11:02 PM, Anthony Liguori wrote: >>>>>> Mohammed Gamal wrote: >>>>>>> On Thu, Jul 10, 2008 at 7:31 PM, Anthony Liguori >>>>>>> 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 >>> >>> >>>>> 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 Yes, we have TF set (I checked for this initially as well, but I starred at the wrong nibble). Here is the related code from himem.exe (himem64.asm [1]): > ;****************************************************************************** > ; 16-bit transient code and data. only used once. > ;****************************************************************************** > ; checks if CPU is a 386 > ; In: nothing > ; Out: CY=0 - processor is a 386 or higher > ; CY=1 - processor lower than 386 > > proc check_cpu > pushf > xor ax,ax > push ax > popf > pushf > pop ax > and ah,0fh > cmp ah,0fh > je not386 > mov ah,7 > push ax > popf > pushf Here we crash (with my patch) or report a break to the host (vanilla) instead of delivering a #DB trap to the guest. > pop ax > and ah,7 > je not386 > popf > clc > ret > not386: > popf > stc > ret > endp check_cpu > 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) . It looks like that we should forward all #DB exceptions to the guest in real mode unless we are sure they were caused by a host-injection. Here is more or less a hack to achieve this (breaking guest debugging for now): diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index b60fcec..a6f9c9b 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -2244,6 +2244,15 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu, if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0) if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE) return 1; + /* + * Forward #DB + * FIXME: Quick-hack, breaks guest debugging in real mode, will be + * fixed with the required debugging infrastructure rework. + */ + if (vec == 1) { + vmx_inject_irq(vcpu, vec); + return 1; + } return 0; } /me now wonders if there are not even more exceptions that have to be forwarded. Right now we catch them all, but I did not find some path via which actual ones are pushed to the guest. Jan PS: The check for vcpu->arch.rmode.active is handle_rmode_exception is redundant.