[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 13:00:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 27/05/2015 11:36, Avi Kivity wrote:
> On 05/27/2015 12:30 PM, Paolo Bonzini wrote:
>> On 26/05/2015 23:25, Christopher Covington wrote:
>>> On 05/25/2015 08:53 AM, Paolo Bonzini wrote:
>>>> On 22/05/2015 13:12, Daniel P. Berrange wrote:
>>>>> In
>>>>> particular I don't see why we need to have a SATA controller and
>>>>> ISA/LPC
>>>>> bridge in every virt machine - root PCI bus only should be
>>>>> possible, as you
>>>>> can provide disks via virtio-blk or virtio-scsi and serial,
>>>>> parallel, mouse,
>>>>> floppy via PCI devices and/or by adding a USB bus in the cases
>>>>> where you
>>>>> really need one.
>>>> I think removing the ISA/LPC bridge is hard.  It includes the real-time
>>>> clock and fw_cfg, for example.
>>> Could VirtIO specified replacements make sense for these peripherals?
>> Not really.  virtio is too heavyweight and you'd be reinventing the
>> wheel unnecessarily.
>> For example, ARM's "-M virt" uses a pl011 block for the RTC, and also
>> uses fw_cfg.  Another commonly used ISA device is the UART, for which
>> again -M virt uses a pl031.
> The RTC can be replaced by kvmclock, the keyboard by virtio-console. 
> Maybe we can provide an msr- or pci- based interface to fw_cfg.

The RTC is used for more than clock unfortunately.  S3 support uses it
for example, both to tell the firmware that it's an S3 resume and for
resuming when the alarm fires.

All in all, getting rid of ISA seems like chasing windmills.  If you
want to do that, fine, but then do not do that on a minimal firmware
like qboot or SeaBIOS.  For example, UEFI provides run-time services
that let you access some low-level devices like this, and that's part of
why the ARM virtual machine image specification mandates UEFI support.
But even then, the ARM virtual machine image specification lets you
choose between pl031 and a Xen pv console, and doesn't specify



reply via email to

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