From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastian Herbszt" Subject: Re: [SeaBIOS] [PATCHv6 00/16] boot order specification Date: Thu, 2 Dec 2010 22:22:03 +0100 Message-ID: <9DF4B6C669F4454FB3054E9391A25206@FSCPC> References: <20101127190424.GD14385@redhat.com><20101127210744.GA21727@morn.localdomain><20101128074534.GE6897@redhat.com><20101128171543.GA21987@morn.localdomain><20101128184734.GE14385@redhat.com><20101130013402.GB3488@morn.localdomain><20101130140100.GH2187@redhat.com><20101201025332.GA6877@morn.localdomain><20101201122740.GL2187@redhat.com><20101202022540.GA23364@morn.localdomain> <20101202123042.GD2924@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Cc: , , To: "Gleb Natapov" , "Kevin O'Connor" Return-path: Received: from mailout-de.gmx.net ([213.165.64.23]:57073 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP id S1757599Ab0LBVWj (ORCPT ); Thu, 2 Dec 2010 16:22:39 -0500 In-Reply-To: <20101202123042.GD2924@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov wrote: > How can we get to EDD info after device is mapped? Looking at Seabios > implementation it builds EDD table on the fly when int_1348 is called > and it does it only for internal devices. Can we use "disconnect vector" > to connect device temporarily get EDD and then disconnect? >>From BIOS Boot Specification 1.01 "6.4.2 Disconnect Vector Originally, it was thought that the DV would be called by the BIOS if the device's BCV was called and subsequent booting from the device failed. However, it was later discovered that current PnP option ROMs are more well behaved by checking during the BCV call if their device will properly respond to INT 13h calls or not, and simply not hooking INT 13h if those calls would fail. Because of this, the DV is not called by a BIOS supporting the BIOS Boot Specification, nor is it necessary to have a valid DV in the PnP Expansion Header. The DV should be NULL and can't be used for other storage." Sebastian From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47573 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POGpm-0002M0-Uv for qemu-devel@nongnu.org; Thu, 02 Dec 2010 16:37:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POGbw-00010x-BJ for qemu-devel@nongnu.org; Thu, 02 Dec 2010 16:22:41 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]:46988 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1POGbv-00010C-TV for qemu-devel@nongnu.org; Thu, 02 Dec 2010 16:22:40 -0500 Message-ID: <9DF4B6C669F4454FB3054E9391A25206@FSCPC> From: "Sebastian Herbszt" References: <20101127190424.GD14385@redhat.com><20101127210744.GA21727@morn.localdomain><20101128074534.GE6897@redhat.com><20101128171543.GA21987@morn.localdomain><20101128184734.GE14385@redhat.com><20101130013402.GB3488@morn.localdomain><20101130140100.GH2187@redhat.com><20101201025332.GA6877@morn.localdomain><20101201122740.GL2187@redhat.com><20101202022540.GA23364@morn.localdomain> <20101202123042.GD2924@redhat.com> In-Reply-To: <20101202123042.GD2924@redhat.com> Date: Thu, 2 Dec 2010 22:22:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov , Kevin O'Connor Cc: seabios@seabios.org, qemu-devel@nongnu.org, kvm@vger.kernel.org Gleb Natapov wrote: > How can we get to EDD info after device is mapped? Looking at Seabios > implementation it builds EDD table on the fly when int_1348 is called > and it does it only for internal devices. Can we use "disconnect vector" > to connect device temporarily get EDD and then disconnect? >>From BIOS Boot Specification 1.01 "6.4.2 Disconnect Vector Originally, it was thought that the DV would be called by the BIOS if the device's BCV was called and subsequent booting from the device failed. However, it was later discovered that current PnP option ROMs are more well behaved by checking during the BCV call if their device will properly respond to INT 13h calls or not, and simply not hooking INT 13h if those calls would fail. Because of this, the DV is not called by a BIOS supporting the BIOS Boot Specification, nor is it necessary to have a valid DV in the PnP Expansion Header. The DV should be NULL and can't be used for other storage." Sebastian