Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
Gleb Natapov wrote: BBS specification is broken since it doesn't provide a way for discovered boot method (BCV) to be linked back to a device it will boot from. Nothing we can do to fix this except moving to EFI (an hope the problem is fixed there). There is that option, or there could be some simple improvement of our own, which works in QEMU and maybe even adds value to coreboot. But then there would be a bit of novel development in firmware - that can't be a good thing, right? Spec says that in that case user probably will want to adjust boot order anyway and will enter boot menu by itself. Sorry excuse for failing to provide proper functionality if you ask me :) I agree. I can not believe the absolute resistance to innovation in this field. Isn't the scope of BBS logic limited to boot time? (There are calls to do settings, but that's no problem.) Maybe it would be possible for SeaBIOS to provide what looks like BBS to the guest, but on the other side there is something more intelligent going on, be it together with QEMU or coreboot? //Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
On Thu, Dec 02, 2010 at 04:07:16PM +0100, Peter Stuge wrote: Gleb Natapov wrote: BBS specification is broken since it doesn't provide a way for discovered boot method (BCV) to be linked back to a device it will boot from. Nothing we can do to fix this except moving to EFI (an hope the problem is fixed there). There is that option, or there could be some simple improvement of our own, which works in QEMU and maybe even adds value to coreboot. But then there would be a bit of novel development in firmware - that can't be a good thing, right? I am all for novel development in firmware, but unfortunately I do not see what can we do in Seabios + qemu to fix this shortcoming. The problem should be fixed in each and every option rom. Option rom may set device address somewhere in pnp header for instance. Spec says that in that case user probably will want to adjust boot order anyway and will enter boot menu by itself. Sorry excuse for failing to provide proper functionality if you ask me :) I agree. I can not believe the absolute resistance to innovation in this field. Interested parties want everyone to move to EFI I guess. Isn't the scope of BBS logic limited to boot time? (There are calls to do settings, but that's no problem.) Maybe it would be possible for SeaBIOS to provide what looks like BBS to the guest, but on the other side there is something more intelligent going on, be it together with QEMU or coreboot? I don't how it can be done without cooperation with option roms. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
Gleb Natapov wrote: There is no way for qemu to know about BCVs or BEVs This is very much the key point. In order to have command line control over the boot process, the machine and the firmware must agree on things. I see two options: 1. QEMU works very very hard to provide a machine that will result in a particular BBS program flow in firmware, in the end resulting in the desired device being used for booting - as long as QEMU and the firmware happen to have the same understanding of the BBS. 2. QEMU passes boot instructions to the firmware based on immediate, common, structured data. The first option seems disgusting to me, because it has many drawbacks and no benefits. The second option requires inventing something that goes beyond the established BIOS standards, maybe a reason for it to see fierce resistance, but it is the only thing that makes sense. Specifying boot device using PCI BDF is a great example of using common structured data. That BDF exists both in machine and firmware data models. The scope of BBS is limited to the firmware, so it is not really practical for creating consistency in a dynamic machine. //Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
Peter Stuge wrote: Specifying boot device using PCI BDF is a great example of using common structured data. That BDF exists both in machine and firmware data models. Gleb Natapov wrote: Bus numbers are assigned by a guest. Qemu knows nothing about them, so it specify device path by topology. Quite. By BDF I of course mean topology. ;) The BDF itself is not much better than a BBS concept, since only the firmware knows the details. But the topology is common, even if bus number differs between machine and firmware. How is the topology structured? I'm not sure that firmware can use a slot number. Device number on the bus works, is that what you mean? //Peter -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote: Gleb Natapov wrote: There is no way for qemu to know about BCVs or BEVs This is very much the key point. In order to have command line control over the boot process, the machine and the firmware must agree on things. I see two options: 1. QEMU works very very hard to provide a machine that will result in a particular BBS program flow in firmware, in the end resulting in the desired device being used for booting - as long as QEMU and the firmware happen to have the same understanding of the BBS. Since qemu knows nothing about BCVs and BEVs it can't implement 1 since it can't know what BBS flow will look like in Seabios. 2. QEMU passes boot instructions to the firmware based on immediate, common, structured data. What is this immediate, common, structured data? This is the crux of the problem really. The first option seems disgusting to me, because it has many drawbacks and no benefits. The second option requires inventing something that goes beyond the established BIOS standards, maybe a reason for it to see fierce resistance, but it is the only thing that makes sense. Specifying boot device using PCI BDF is a great example of using common structured data. That BDF exists both in machine and firmware data models. The scope of BBS is limited to the firmware, so it is not really practical for creating consistency in a dynamic machine. B from BDF does not exists in machine data model. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
On Sun, Nov 28, 2010 at 08:11:45PM +0100, Peter Stuge wrote: Peter Stuge wrote: Specifying boot device using PCI BDF is a great example of using common structured data. That BDF exists both in machine and firmware data models. Gleb Natapov wrote: Bus numbers are assigned by a guest. Qemu knows nothing about them, so it specify device path by topology. Quite. By BDF I of course mean topology. ;) Ah, then we are in violent agreement :) The BDF itself is not much better than a BBS concept, since only the firmware knows the details. Yeap. But the topology is common, even if bus number differs between machine and firmware. Correct. How is the topology structured? I'm not sure that firmware can use a slot number. Device number on the bus works, is that what you mean? To specify device path to PCI card using topology one needs to specify slot.fn of all pci-to-pci buses from pci host controller to pci device in question. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
