From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36258) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XobJc-0004KR-9c for qemu-devel@nongnu.org; Wed, 12 Nov 2014 12:02:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XobJW-00031h-7Y for qemu-devel@nongnu.org; Wed, 12 Nov 2014 12:02:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XobJV-00031K-Vj for qemu-devel@nongnu.org; Wed, 12 Nov 2014 12:02:38 -0500 Message-ID: <546389F3.4040508@redhat.com> Date: Wed, 12 Nov 2014 17:25:23 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20141030180216.GD31629@leverpostej> <1690954.Y528jzYjum@wuerfel> <5463850E.7020703@redhat.com> <4532823.qiucXlCzCt@wuerfel> In-Reply-To: <4532823.qiucXlCzCt@wuerfel> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnd Bergmann Cc: Peter Maydell , "Ian.Campbell@citrix.com" , linaro-acpi@lists.linaro.org, Claudio Fontana , QEMU Developers , "stefano.stabellini@citrix.com" , "tech@virtualopensystems.com" , Parth Dixit , Christoffer Dall 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