From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU Date: Wed, 27 May 2015 14:59:35 +0200 Message-ID: <5565BFB7.7000406@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: qemu-devel , KVM list To: Christopher Covington , "Daniel P. Berrange" , Peter Maydell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:52597 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbbE0M7q (ORCPT ); Wed, 27 May 2015 08:59:46 -0400 In-Reply-To: <5565BD9D.2030305@codeaurora.org> Sender: kvm-owner@vger.kernel.org List-ID: 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