Libreboot 2021 libvirt/kvm issues

2 risposte [Ultimo contenuto]
JamesT400
Offline
Iscritto: 03/03/2020

I am wondering if and how I can enable kvm on the 2021 release of libreboot(?). I can run kvm on the 2016 release just fine, but the two new 2021 releases do not allow kvm on my T400. Is there a way to get kvm enabled like in the 2016 version? Other than that, I really like the beta releases, so I would rather not have to downgrade.

Thanks for any input on that.

SkedarKing
Offline
Iscritto: 11/01/2021

I haven't tried 2021's libreboot, so I cannot tell you how to fix this, although... I Thought they had released a stable version, although this appears not to be the case.

Either way, if you want more stability and privacy/security but are okay with intel me only being disabled and not removed, use osboot which also has yet to release a new stable...

Also, it has none yet alas...

I recommend you wait a bit, or use the last libreboot release... otherwise either way, you are stuck waiting for this to be fixed...

:(

libreleah
Offline
Iscritto: 04/03/2017

cpu microcode updates are needed for stable kvm

use osboot instead, or add microcode to your libreboot rom:

cbfstool libreboot.rom add -f cpu_microcode_blob.bin -n cpu_microcode_blob.bin -t microcode

edit:

in case it's unclear:

this has been known since these machines were ever added to libreboot. i knew it since then, and it has been written as such on libreboot.org too. i'm planning an overhaul of libreboot and osboot, especially in documentation pertaining to this subject. i need to be more clear

until then:

copy pasta:

Unlike Libreboot, osboot includes CPU microcode updates by default. On systems that Libreboot also supports, this is the only difference. Intel CPUs have configurable logic gate arrays inside them, which the microcode configures to implement an instruction set. This is referred to as *microprogramming*. Some people regard the microcode is *software* that must be freed, but in reality, there is only so much room to deviate before you end up with a very broken CPU on which software no longer runs correctly. Intel provides these updates, freely redistributable, to the general public, and projects like osboot can use them:

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tree/main/intel-ucode

Without the microcode updates, these CPUs can sometimes crash, and certain features (such as hardware-based virtualization) may become unreliable. These updates correct errors in the original microcode, allowing for more stable operation. The updates must be re-applied during every boot cycle, and this is performed automatically by osboot.

Not including these updates will result in an unstable/undefined state. Intel themselves define which bugs affect which CPUs, and they define workarounds, or provide fixes in microcode. Based on this, software such as the Linux kernel can work around those bugs/quirks. Also, upstream versions of the Linux kernel can update the microcode at boot time (however, it is recommend still to do it from coreboot, for more stable memory controller initialization or “raminit”).

Here are some examples of where lack of microcode updates affected Libreboot, forcing Libreboot to work around changes made upstream in coreboot, changes that were *good* and made coreboot behave in a more standards-compliant manner as per Intel specifications. Libreboot had to *break* coreboot to retain certain other functionalities:

https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdf...

https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc...

These patches revert *bug fixes* in coreboot. These bug fixes happen to break *other* features, when microcode updates are not applied, but coreboot correctly considers the no-microcode situation to be technically invalid. The coreboot code is correct.

In Libreboot, our only choices were: broken reboot + broken speedstep on some machines, or break something *else* to fix these. In both cases, coreboot was correcting something upstream, to fix old, non-compliant behaviour in the coreboot logic. The most optimal solution is to *not* apply the above patches, but Libreboot has no viable alternative.

osboot does not need the two patches listed above, since it includes the microcode updates. It is superior to Libreboot, for this reason. However, Libreboot still works quite nicely for most people, and I’m still happy to give Libreboot to people, instead of osboot, if they ask for it.