On Wednesday 12 November 2014 17:04:30 Paolo Bonzini wrote:
On 12/11/2014 16:57, Arnd Bergmann wrote:
It seems to me like complicated stuff like that definitely belongs in the UEFI/bootloader blob, though. I'd rather QEMU just modelled the hardware and let the guest (or the firmware, which is guest code from QEMU's point of view) set it up however it wants.
It definitely doesn't belong in QEMU!
The easiest option would probably be not make all PCI devices have fixed BARs and not even allow them to be changed. I believe this is what kvmtool does, but I can see how supporting both modes is much harder than either one.
kvmtool does not have firmware; it starts the kernel directly, so it does all the setup that usually is done by the firmware. It implements a couple real-mode interfaces that Linux uses when booting, but nothing of this deals with PCI.
x86 QEMU always runs firmware. Even if you specify -kernel, the firmware does all the usual initialization and then boots from a small ROM. The ROM contains the bootloader, so it loads and starts the kernel.
Ok, I see.
How does it work on x86 with qemu?
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.
Arnd