On 17/12/2019 22:41, Eslam Elnikety wrote: > On 13.12.19 14:57, Andrew Cooper wrote: >> 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 had in mind microcode speculation mitigation features when reasoning > with the minimum patch level argument.
Considering how well the first round of speculative microcode went, mandating it would have been a rather bad thing... But yes - as a usecase of "I wish to bundle the minimum microcode I'd like to work with", this seems entirely reasonable. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
