From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM and OS/2: #UD in real mode Date: Thu, 24 Jan 2008 08:33:17 +0200 Message-ID: <4798312D.9060204@qumranet.com> References: <4796AB3F.5070407@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: "H. Peter Anvin" Return-path: In-Reply-To: <4796AB3F.5070407-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org H. Peter Anvin wrote: > Just for fun, I tried to boot OS/2 Warp 4.0 under KVM (KVM-59 with the > latest git kernel from Linus as of yesterday, slightly post 2.6.24-rc8.) > I found that it crashes very early, apparently because KVM doesn't > handle an #UD received in user mode. It appears that OS/2 actually > provokes an #UD deliberately in real mode, from the disassembly it looks > like it's trying to probe for the 486 version of cmpxchg (which has a > different opcode than the 586+ version.) > Strange, the manual lists 0f b0 and 0f b1 as compatible all the way back to the 486. What opcode are you seeing? > It looks like the kernel code filters out a very small number of > real-mode exceptions, and does a KVM exit for all the other ones; the > userspace code then unconditionally barfs. This is presumably a > temporary hack; what is the intended behaviour - for this to be handled > in-kernel, or in userspace? > In kernel. I've never seen a #UD in real mode, that's why it isn't handled. -- Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/