From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: [Regression] kvm-userspace: VM freezes after booting FreeDOS
Date: Sun, 13 Jul 2008 12:55:38 +0300
Message-ID: <4879D11A.9090900@qumranet.com>
References: <52d4a3890807100847q5aef1a69hbd7179b018cb02ad@mail.gmail.com>	 <48763963.3010406@codemonkey.ws>	 <52d4a3890807101252h13c24b0ej35b4af71ac6b5b58@mail.gmail.com>	 <48766AE0.2050400@codemonkey.ws>	 <52d4a3890807101332v2cfe5604g78dc2d225e3c67d9@mail.gmail.com>	 <48767DB3.7090701@web.de>	 <52d4a3890807101559i408e3d3at8030034e858f0256@mail.gmail.com>	 <48773BA3.7090900@siemens.com> <52d4a3890807110755j4c501040y4749181ccfc33420@mail.gmail.com> <4878934E.70504@web.de> <4879B4AC.1070809@qumranet.com> <4879C636.30003@web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mohammed Gamal <m.gamal005@gmail.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Anthony Liguori <anthony@codemonkey.ws>, kvm@vger.kernel.org,
	Rik van Riel <riel@surriel.com>
To: Jan Kiszka <jan.kiszka@web.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from il.qumranet.com ([212.179.150.194]:39527 "EHLO il.qumranet.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751311AbYGMJzm (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 13 Jul 2008 05:55:42 -0400
In-Reply-To: <4879C636.30003@web.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Jan Kiszka wrote:
>>>     
>>>       
>> But it seems the best thing to do is not to trap #DB in
>> update_exception_bitmap()?
>>     
>
> Was my first idea as well. I do not understand what is going on there,
> but when I simply exclude #DB from the exception bitmap in real mode,
> the problem pops up again: #GP on the instruction that should raise the #DB.
>
>   

Right.  The docs say that a #DB (like all exceptions) will trap to the 
protected mode handler through the #GP exception.

So, we do need kvm_queue_exception.

>>> /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.
>>>       
>> Looks like update_exception_bitmap() assumes none.  From a cursory look,
>> seems like #DE (divide error), #DB, #BP (Breakpoint), #OF (overflow),
>> #BR (range check) all need to be passed to the guest.
>>     
>
> Hmm, unless KVM did something to fix up some exception, shouldn't all of
> them be passed?
>   

Yes, they should.  But it can't be done using the exception bitmap.

-- 
error compiling committee.c: too many arguments to function