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
