Re: [Regression] kvm-userspace: VM freezes after booting FreeDOS

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 5422 bytes --]

Mohammed Gamal wrote:
> On Fri, Jul 11, 2008 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Mohammed Gamal wrote:
>>> On Fri, Jul 11, 2008 at 12:22 AM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> Mohammed Gamal wrote:
>>>>> On Thu, Jul 10, 2008 at 11:02 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>>>> Mohammed Gamal wrote:
>>>>>>> On Thu, Jul 10, 2008 at 7:31 PM, Anthony Liguori <anthony@codemonkey.ws>
>>>>>>> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]