Mohammed Gamal wrote: > 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
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.
signature.asc
Description: OpenPGP digital signature
