[Top][All Lists]

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

Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU

From: Paolo Bonzini
Subject: Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
Date: Wed, 27 May 2015 14:59:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.


reply via email to

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