From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Handling vmentry failures in userspace Date: Sun, 20 Jul 2008 15:31:18 +0300 Message-ID: <48833016.4050103@qumranet.com> References: <52d4a3890807200527u17b6d22qa1afaeb8133eaf43@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm-devel , Rik van Riel , Guillaume Thouvenin To: Mohammed Gamal Return-path: Received: from il.qumranet.com ([212.179.150.194]:28668 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756778AbYGTMbU (ORCPT ); Sun, 20 Jul 2008 08:31:20 -0400 In-Reply-To: <52d4a3890807200527u17b6d22qa1afaeb8133eaf43@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: Mohammed Gamal wrote: > With the unpredictable behaviour of the current vmentry failure patch, > I think this is caused by external interrupts from the host, and since > this is hard to control I was thinking of handling vmentry failure in > userspace. The way I am thinking of doing it is that once a vmentry > fails because of an invalid guest state we delegate the emulation to > userspace, and then we'd rely on QEMU's CPU emulation to emulate > instructions until we return to VMX-friendly state. > > I don't have a strong grasp of the details on how the kernel- and > user-space side interact, so I don't know if that'd really be > possible? If it is, is it plausible to do it this way, or is it better > to leave all handling within the kernel side? > Userspace emulation doesn't work. Some of the emulated devices are in the kernel; getting smp right in userspace is hard; and most importantly doing some of the cpu emulation in userspace means that the boundary between the kernel and userspace is blurred, making it difficult to write alternative userspaces. Fixing the problems we have may be hard, but we need to do this right. -- error compiling committee.c: too many arguments to function