From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Regression] kvm-userspace: VM freezes after booting FreeDOS Date: Sun, 13 Jul 2008 10:54:20 +0300 Message-ID: <4879B4AC.1070809@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mohammed Gamal , Jan Kiszka , Anthony Liguori , kvm@vger.kernel.org, Rik van Riel To: Jan Kiszka Return-path: Received: from il.qumranet.com ([212.179.150.194]:52374 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751808AbYGMHyW (ORCPT ); Sun, 13 Jul 2008 03:54:22 -0400 In-Reply-To: <4878934E.70504@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > 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) { > DB_VECTOR > + vmx_inject_irq(vcpu, vec); > kvm_queue_exception() > + return 1; > + } > return 0; > } > > But it seems the best thing to do is not to trap #DB in update_exception_bitmap()? > /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. -- error compiling committee.c: too many arguments to function