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 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.

> 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.

Paolo