Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
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. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 27/05/2015 13:54, Peter Maydell wrote: On 27 May 2015 at 10:30, Paolo Bonzini pbonz...@redhat.com wrote: 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. Partly we do that because there were a number of reports that trying to use virtio for the console didn't work reliably... Using the stock UART that is widely supported in UEFI/uboot/kernel was a conservative design choice. The next thing that's likely to appear in virt is a PL061 GPIO device, which you need for CPU hotplug and external-shutdown-request notifications. Indeed, and the x86 Q35 chipset puts the ACPI registers... in the ISA/LPC bridge. :) Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 27 May 2015 at 10:30, Paolo Bonzini pbonz...@redhat.com wrote: 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. Partly we do that because there were a number of reports that trying to use virtio for the console didn't work reliably... Using the stock UART that is widely supported in UEFI/uboot/kernel was a conservative design choice. The next thing that's likely to appear in virt is a PL061 GPIO device, which you need for CPU hotplug and external-shutdown-request notifications. -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 05/27/2015 05:30 AM, 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 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? 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. 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. (UART is PL011; RTC is PL031) Thanks, Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
* Paolo Bonzini (pbonz...@redhat.com) 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. I see reasons to replace some but not all these components; and there's no point in replacing the ISA/LPC bridge since it's got nothing at all in it. 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. I don't see much point in replacing the simple PC uart with anything virtio; I can imagine that you might want to go down to something really trivial with non of the bells and whistles; but a UART is pretty simple. The PC RTC though, it's a bit of a disaster that's had 30 years of random cruft added into it to hold random things that should never have been there. Dave Paolo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
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? Chris -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
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. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On Thu, May 21, 2015 at 03:51:43PM +0200, Paolo Bonzini wrote: Some of you may have heard about the Clear Containers initiative from Intel, which couple KVM with various kernel tricks to create extremely lightweight virtual machines. The experimental Clear Containers setup requires only 18-20 MB to launch a virtual machine, and needs about 60 ms to boot. Now, as all of you probably know, QEMU is great for running Windows or legacy Linux guests, but that flexibility comes at a hefty price. Not only does all of the emulation consume memory, it also requires some form of low-level firmware in the guest as well. All of this adds quite a bit to virtual-machine startup times (500 to 700 milliseconds is not unusual). Right? In fact, it's for this reason that Clear Containers uses kvmtool instead of QEMU. No, wrong! In fact, reporting bad performance is pretty much the same as throwing down the gauntlet. On the QEMU side of things I wonder if there is scope for taking AArch64's 'virt' machine type concept and duplicating it on all architectures. It would be nice to have a common minimal machine type on all architectures that discards all legacy platform stuff and focuses on the minimum needed to run modern virtual machine optimized guest OS. People would always know that a machine type called 'virt' was the minimal virtualization platform, while the others all target emulation of realworld (legacy) baremetal platforms. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 22 May 2015 at 12:01, Daniel P. Berrange berra...@redhat.com wrote: On the QEMU side of things I wonder if there is scope for taking AArch64's 'virt' machine type concept and duplicating it on all architectures. Experience suggests that holding the line on minimal is really quite tricky, though -- there's always one more thing that somebody really wants to add... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On Fr, 2015-05-22 at 12:21 +0100, Peter Maydell wrote: On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote: Yep, it is hard saying no - but I'd think as long as it was possible to add the extra features using -device, it ought to be practical to keep a virt machine types -nodefaults -nodefconfig base setup pretty minimal. Mmm, but -device only works for pluggable devices really. We don't have a coherent mechanism for saying put the PS/2 keyboard controller into the system at its usual IO ports on the command line. Do we need that in the first place? You can plugin a usb keyboard today. You'll be able to plugin a virtio keyboard soon. I think alot of hardware where this applies to is the legacy stuff we want to get rid of for '-M virt' ... cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote: Yep, it is hard saying no - but I'd think as long as it was possible to add the extra features using -device, it ought to be practical to keep a virt machine types -nodefaults -nodefconfig base setup pretty minimal. Mmm, but -device only works for pluggable devices really. We don't have a coherent mechanism for saying put the PS/2 keyboard controller into the system at its usual IO ports on the command line. -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On Fri, May 22, 2015 at 12:04:54PM +0100, Peter Maydell wrote: On 22 May 2015 at 12:01, Daniel P. Berrange berra...@redhat.com wrote: On the QEMU side of things I wonder if there is scope for taking AArch64's 'virt' machine type concept and duplicating it on all architectures. Experience suggests that holding the line on minimal is really quite tricky, though -- there's always one more thing that somebody really wants to add... Yep, it is hard saying no - but I'd think as long as it was possible to add the extra features using -device, it ought to be practical to keep a virt machine types -nodefaults -nodefconfig base setup pretty minimal. 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. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On Fri, May 22, 2015 at 12:21:27PM +0100, Peter Maydell wrote: On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote: Yep, it is hard saying no - but I'd think as long as it was possible to add the extra features using -device, it ought to be practical to keep a virt machine types -nodefaults -nodefconfig base setup pretty minimal. Mmm, but -device only works for pluggable devices really. We don't have a coherent mechanism for saying put the PS/2 keyboard controller into the system at its usual IO ports on the command line. Oh, I didn't neccessarily mean that we'd need the ability to add a ps/2 keyboard via -device. I meant that there just need to be able to add /some/ kind of keyboard. eg we have a usb-kbd device that could potentially fill that role. Likewise for mouse pointer. Serial ports, etc. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
Peter Maydell peter.mayd...@linaro.org writes: On 22 May 2015 at 12:12, Daniel P. Berrange berra...@redhat.com wrote: Yep, it is hard saying no - but I'd think as long as it was possible to add the extra features using -device, it ought to be practical to keep a virt machine types -nodefaults -nodefconfig base setup pretty minimal. Mmm, but -device only works for pluggable devices really. We don't have a coherent mechanism for saying put the PS/2 keyboard controller into the system at its usual IO ports on the command line. ... yet. The qdev long-term vision has always been to support starting with an empty board, then add device models and their wiring. Unfortunately, progress towards that goal has been slow. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
Hi, qboot is available at git://github.com/bonzini/qboot.git. Firmware repo has packages now. https://www.kraxel.org/repos/firmware.repo https://www.kraxel.org/repos/jenkins/qboot/ enjoy, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 05/21/2015 07:21 PM, Paolo Bonzini wrote: On 21/05/2015 17:48, Avi Kivity wrote: Lovely! Note you have memcpy.o instead of memcpy.c. Doh, and it's not used anyway. Check the repository, and let me know if OSv boots with it (it probably needs ACPI; Linux doesn't boot virtio without ACPI). Yes, it requires ACPI. We don't implement the pre-ACPI bootstrap methods. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 05/21/2015 04:51 PM, Paolo Bonzini wrote: Some of you may have heard about the Clear Containers initiative from Intel, which couple KVM with various kernel tricks to create extremely lightweight virtual machines. The experimental Clear Containers setup requires only 18-20 MB to launch a virtual machine, and needs about 60 ms to boot. Now, as all of you probably know, QEMU is great for running Windows or legacy Linux guests, but that flexibility comes at a hefty price. Not only does all of the emulation consume memory, it also requires some form of low-level firmware in the guest as well. All of this adds quite a bit to virtual-machine startup times (500 to 700 milliseconds is not unusual). Right? In fact, it's for this reason that Clear Containers uses kvmtool instead of QEMU. No, wrong! In fact, reporting bad performance is pretty much the same as throwing down the gauntlet. Enter qboot, a minimal x86 firmware that runs on QEMU and, together with a slimmed-down QEMU configuration, boots a virtual machine in 40 milliseconds[2] on an Ivy Bridge Core i7 processor. qboot is available at git://github.com/bonzini/qboot.git. In all the glory of its 8KB of code, it brings together various existing open source components: * a minimal (really minimal) 16-bit BIOS runtime based on kvmtool's own BIOS * a couple hardware initialization routines written mostly from scratch but with good help from SeaBIOS source code * a minimal 32-bit libc based on kvm-unit-tests * the Linux loader from QEMU itself The repository has more information on how to achieve fast boot times, and examples of using qboot. Right now there is a limit of 8 MB for vmlinuz+initrd+cmdline, which however should be enough for initrd-less containers. The first commit to qboot is more or less 24 hours old, so there is definitely more work to do, in particular to extract ACPI tables from QEMU and present them to the guest. This is probably another day of work or so, and it will enable multiprocessor guests with little or no impact on the boot times. SMBIOS information is also available from QEMU. On the QEMU side, there is no support yet for persistent memory and the NFIT tables from ACPI 6.0. Once that (and ACPI support) is added, qboot will automatically start using it. Happy hacking! Lovely! Note you have memcpy.o instead of memcpy.c. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU
On 21/05/2015 17:48, Avi Kivity wrote: Lovely! Note you have memcpy.o instead of memcpy.c. Doh, and it's not used anyway. Check the repository, and let me know if OSv boots with it (it probably needs ACPI; Linux doesn't boot virtio without ACPI). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
