From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml6lf-0003A3-1S for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:54:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml6la-00039U-Hp for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:54:18 -0400 Received: from [199.232.76.173] (port=56263 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml6la-00039Q-DP for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:54:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21345) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ml6lZ-0004wS-Tw for qemu-devel@nongnu.org; Tue, 08 Sep 2009 15:54:14 -0400 Message-ID: <4AA6B7E2.40703@redhat.com> Date: Tue, 08 Sep 2009 23:00:34 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/2] port over extboot from kvm References: <1252401463-3249-1-git-send-email-kraxel@redhat.com> <4AA6607C.4050505@siemens.com> <4AA668A2.1080801@redhat.com> <4AA66B10.2050901@codemonkey.ws> <4AA680BB.5020201@redhat.com> <4AA692A0.1070006@codemonkey.ws> <4AA6AC56.5020700@redhat.com> <4AA6B499.5060103@codemonkey.ws> In-Reply-To: <4AA6B499.5060103@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Gerd Hoffmann , qemu-devel@nongnu.org On 09/08/2009 10:46 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> The bios exports the "bios drives". You can tell grub to load a >> kernel from the first partition of the second disk: (hd1,0) or even >> chain-load another boot loaded from another disk. > > The whole point of device.map is that grub doesn't intrinsically know > how to map from bios drives to real drives. device.map is a wonderful thing, but unrelated to the bios exposing drive 0x81. > In fact, when you chain-load with grub, you often have to "swap" > device mappings which has the effect of hooking int13 and faking the > primary drive for another OS. See > http://www.gnu.org/software/grub/manual/html_node/DOS_002fWindows.html But grub still has to issue a real int 13 for drive 0x81. If we don't expose it, it can't. Until a real OS is loaded, the only way to access a drive is through int 13 and if we don't expose it, it's invisible. > All else aside, from a BIOS perspective, you can usually only boot > from 0x80 and that can be mapped to different drives via BCV. There things you can do with a drive other than boot it. For example, access it via int 13. How will you access D:\ from DOS? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.