qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI


From: Arnd Bergmann
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Wed, 12 Nov 2014 17:13:48 +0100
User-agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]