On 12/11/2014 17:13, Arnd Bergmann wrote:
Same as real hardware. Firmware (SeaBIOS or OVMF) builds the memory map, decides where in the free space the BARs go, and programs the PCI devices accordingly.
kvmtool is the special one here. Xen, VMware, Hyper-V all do the same as QEMU.
Right. I guess embedded ARM images in qemu are a third way then, because these don't have a guest firmware but also don't set up the hardware the way that kvmtool does.
Claudio's request to do this differently on arm64 seems absolutely reasonable to me, but I guess that implies having UEFI or something like it that does the PCI scan. Not sure what the best default for "qemu -kernel image" should be though if you don't explicitly pass a firmware image.
The PowerPC folks are using u-boot as the firmware. I know Peter disagrees, but I don't understand why so I'll throw this up for discussion too; it is definitely lighter-weight than UEFI. Would that make sense for ARM?
I just stumbled upon patches that port u-Boot to bare x86 (no SeaBIOS): http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/201885 -- they have to do the same PCI BAR initialization that Claudio is doing in OSv. Could Claudio build a u-boot ROM that sets up PCI and then automatically loads the OSv kernel?
Paolo