From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxaw4-00014d-07 for qemu-devel@nongnu.org; Wed, 27 May 2015 08:59:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yxavy-0000Nd-0d for qemu-devel@nongnu.org; Wed, 27 May 2015 08:59:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxavx-0000My-Ou for qemu-devel@nongnu.org; Wed, 27 May 2015 08:59:45 -0400 Message-ID: <5565BFB7.7000406@redhat.com> Date: Wed, 27 May 2015 14:59:35 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <555DE2EF.1000509@redhat.com> <20150522110136.GF14428@redhat.com> <20150522111259.GG14428@redhat.com> <55631B3A.7080803@redhat.com> <5564E4C9.8010906@codeaurora.org> <55658EAB.3010107@redhat.com> <5565BD9D.2030305@codeaurora.org> In-Reply-To: <5565BD9D.2030305@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christopher Covington , "Daniel P. Berrange" , Peter Maydell Cc: qemu-devel , KVM list On 27/05/2015 14:50, Christopher Covington wrote: >> Not really. virtio is too heavyweight > > I'd be curious to read where in your estimation this weight lies. Is it > one-time initialization or recurring? Is it specific to the PCI transport or > does MMIO suffer from it as well? It's heavyweight in the sense that virtio requires you to design a communication mechanism based on ring buffers. It's much harder than a few ad-hoc registers. And I know everyone is upset about the attack surface of QEMU these days, but effort would be much better spent adding QEMU-specific customizations to a static analysis tool (that e.g. would derive bound checks for the MemoryRegion read/write ops and be able to prove that said ops cannot access arrays out of their bounds). >> and you'd be reinventing the wheel unnecessarily. > > In my mind the utility of peripherals that are instruction set architecture > agnostic and can work over several transports is in reducing the amount of > (emulator/hypervisor, firmware, and OS) code used, and therefore in need of > maintenance, for common system emulation and virtualization use cases. A fully processor-agnostic hardware architecture is a non-goal. You'll always have stuff like interrupt controllers that is extremely tied to the processor. If you want to abstract hardware, use the firmware, Luke! Things such as UEFI and ACPI are there for exactly this reason. We will be able to reuse a lot of x86 hotplug code on ARM using ACPI. And if you don't want to use ACPI, you can always write native OS drivers for the same hotplug hardware. Paolo