Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini <pbonzini@redhat.com>]

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