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
