From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: qemu oddness with isolinux vesamenu.c32 Date: Fri, 18 Jul 2008 09:25:23 -0700 Message-ID: <4880C3F3.6010202@zytor.com> References: <48800A9D.1080403@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pjones@redhat.com, kvm@vger.kernel.org, Anthony Liguori To: Matt_Domsch@Dell.com Return-path: Received: from terminus.zytor.com ([198.137.202.10]:59080 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755036AbYGRQ0v (ORCPT ); Fri, 18 Jul 2008 12:26:51 -0400 In-Reply-To: <48800A9D.1080403@zytor.com> Sender: kvm-owner@vger.kernel.org List-ID: [Resend corrected destinations] H. Peter Anvin wrote: >> >> hope this helps > > Cc: the kvm-devel list in the hope that they might be able to shed some > light on this. > > What this means is that an expansion ROM located in the ISA expansion > area at segment D000 tried to call the DOS interrupt INT 2Ch with > AX=42C4h. I believe INT 2Ch is a no-op in DOS, but does something in > the NT kernel. > > The CS:IP of the call was D000:04F0. > > I have no idea what would do this; nothing in the command line list > stands out as anything which would install an expansion ROM image into > the VM. > > Either way, it would be good to find out what the idea of calling INT > 2Ch here is. > Never mind, I tracked it down; it's the extboot extension to KVM. /* save old int 19 at int 2b */ [...] /* save old int 13 to int 2c */ This is highly unsafe behaviour, *especially* given the choice of vectors (int 20-3f are used by any DOS-like operating system, and Syslinux uses them for compatibility with DOS.) Some BIOSes do this kind of things, but they use vectors in the range 0xc0-0xef. The use of these vectors is platform-dependent, but since KVM controls the platform, that is relatively safe. Furthermore, it is completely unnecessary. Instead of stuffing the old pointer in an interupt vector and using the INT instruction, stuff it in a variable in the local code segment, and use the following sequence: pushf lcallw *%cs:old_vector In order to do this it needs, of course, to be able to write to its own memory, which I'm not sure if qemu-kvm allows by default. If so, this is actually a defect in qemu-kvm, since modern expansion "ROMs" *do* expect to be able to write to their own memory areas during initialization; see the PnPBIOS spec, Appendix B; support for this specification is mandatory for PCI systems. -hpa