From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: KVM crash on unusual PM->RM transition Date: Tue, 14 Apr 2009 08:48:22 -0700 Message-ID: <49E4B046.5040008@zytor.com> References: <49E3CDE1.8010001@zytor.com> <49E42260.7030009@zytor.com> <49E445C9.3000105@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from terminus.zytor.com ([198.137.202.10]:50817 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750839AbZDNPsj (ORCPT ); Tue, 14 Apr 2009 11:48:39 -0400 In-Reply-To: <49E445C9.3000105@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: >> >> It looks like KVM will simply crash when it runs into a real-mode state >> it can't approximate with V86 mode. I guess I had the failed notion >> that it would kick back such "impossible" states to Qemu. > > Exactly. There's the emulate_invalid_guest_state module parameter which > tells kvm to emulate during such state instead. But this will often > break as programs leave fs and gs in non-v86-mode compliant, requiring > more of the emulator than it currently provides. > Any reason to not make use of Qemu in userspace, rather than relying on the in-kernel interpreter for these? The kernel interpreter is obviously The Right Thing to avoid frequent ping-pong into the kernel, but it seems to me that such a potential "long-term" situation might be better handled by Qemu? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.