On 12/12/2019 22:13, Eslam Elnikety wrote: >>> Second, there is often need to couple a Xen build with a minimum >>> microcode patch level. Having the microcode built within the Xen image >>> itself is a streamlined, natural way of achieving that. >> >> Okay, I can accept this as a reason, to some degree at least. Yet >> as said elsewhere, I don't think you want then to override a >> possible "external" ucode module with the builtin blobs. Instead >> the newest of everything that's available should then be loaded. > > Extending Xen to work around tools shortcomings is absolutely not what > I have in mind. I should have started with the second reason. Read > this as: Xen relies on a minimum microcode feature set, and it makes > sense to couple both in one binary. This coupling just happens to > provide an added benefit in the face of tools shortcoming.
Do we have anything which strictly relies on a minimum version? I can definitely see the value of bundling the ucode and saying "this is the minimum we will tolerate" from a supportability point of view. There is also value when it comes to easier SRTM/DRTM measurements of the system in question, including cases where Xen sits on a boot ROM rather than on disk. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
