On Thu, Aug 06, 2015 at 02:52:16PM +0200, Marc MarĂ wrote:
On Thu, 6 Aug 2015 13:38:33 +0100 Stefan Hajnoczi stefanha@gmail.com wrote:
On Thu, Aug 6, 2015 at 12:02 PM, Marc MarĂ markmb@redhat.com wrote:
case IPL_TYPE_BEV:
boot_rom(ie->vector);
if (qemu_cfg_dma_enabled()) {
boot_linux_cfg_dma();
} else {
boot_rom(ie->vector);
} break;
I thought the fw_cfg DMA interface is equivalent to the PIO interface?
Therefore, your Linux loading code completely replaces the linuxboot.rom. Why would you want to keep using linuxboot.rom in the PIO case if SeaBIOS now has to code to launch the kernel?
By the way, I think this change is incorrect. We shouldn't hijack the BEV. Instead fw_cfg should simply add a higher priority IPL entry when the kernel file is present. That way we just don't execute the option ROM.
linuxboot.rom is doing all the work of reading and copying the kernel to the correct position through the PIO interface, in assembly. If we want to speed up the kernel copying with DMA, it is necessary to change it, and implementing fw_cfg DMA in C is a lot easier.
This new boot is independent of PIO or DMA, so now linuxboot.rom would not be necessary. I don't know if this is desirable.
In any case, I agree with adding a new IPL.
One can look at boot.c:boot_cbfs() (and its call chain) as an example of how to add a new IPL.
As an aside - if ultimately the goal is to change QEMU so that it no longer uses linuxboot, I wonder if it makes sense to clean up the QEMU<->firmware interface for it. It seems that linuxboot uses 12 old-style fw_cfg entries to pass the kernel. It seems that could be replaced with three new-style fw_cfg "file" entries - "/vmlinuz", "/initrd", and "/cmdline" - and QEMU could avoid having to parse and manipulate the vmlinuz contents. I'm guessing all the old-style fw_cfg entries were implemented to make the linuxboot assembler easier. That shouldn't be necessary with SeaBIOS though. Just something to think about - it shouldn't be a pre-requisite for the fw_cfg dma stuff.
-Kevin