From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM crash on unusual PM->RM transition Date: Tue, 14 Apr 2009 19:07:22 +0300 Message-ID: <49E4B4BA.8010801@redhat.com> References: <49E3CDE1.8010001@zytor.com> <49E42260.7030009@zytor.com> <49E445C9.3000105@redhat.com> <49E4B046.5040008@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: "H. Peter Anvin" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59751 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752152AbZDNQGv (ORCPT ); Tue, 14 Apr 2009 12:06:51 -0400 In-Reply-To: <49E4B046.5040008@zytor.com> Sender: kvm-owner@vger.kernel.org List-ID: H. Peter Anvin wrote: > 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? > It's a faq; there are multiple reasons: - it would make the kernel/user interface complicated; right now the model is "kvm emulates the cpu and optionally lapic, ioapic, and pit'; that would change to "kvm sometimes emulates the cpu, but sometimes doesn't". We'd need to add a description of when userspace can jump back into the kernel (AMD for example is perfectly happy in real mode). - it would require a way for userspace to access the in-kernel lapic/ioapic/pit, and for these components to inject interrupts into userspace. - it requires anyone using kvm to implement a complete x86 emulator. - qemu doesn't do smp. with emulate_invalid_guest_space we're actually pretty close to running big real mode; but no one's working on it so it's stagnated. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.