On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote: > W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze: > > > KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware > > built from the edk2 project from a technical POV. > > > > The first challenge will be that many mgmt tools still default to > > using legacy BIOS when deploying guest OS. We've been trying to > > make it easier for mgmt apps to "do the right thing" by having > > libosinfo record metadata about whether each guest OS supports > > legacy BIOS, EFI or both. ie we want the mgmt apps to just pick > > EFI if they see the OS doesn't support legacy BIOS, instead of > > requiring users to manually tell them to use EFI. > > > So I can't say I'm thrilled about a future that depends on EFI for > > virt, but I'm resigned to the fact this is the direction the world > > is taking. So we're not likely to have any choice and will have to > > work to mitigate any downsides it brings. > > Can we also default to Q35 and forget that i440fx existed? > > Do all the pain in one step. That's upto the various mgmt apps using libvirt to decide. Q35 is *NOT* a drop-in replacement for i440fx. IOW if libvirt flipped the switch existing mgmt apps would certainly break. For example, you can't hotplug with Q35, unless the mgmt app pre-populated a bunch of pcie-root-port devices. If the mgmt app is using IDE (eg for CDROM) it'll break because Q35 requires SATA. There's various other areas of pain. So we must let the mgmt apps decide when they are ready to switch to use Q35 instead of i440fx. As an example, OpenStack has been trying to switch to Q35 for over a year, and continues to hit things which are different or broken in Q35, so has been forced to stick with i440fx still. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
