Comment 62 for bug 1828495
Revision history for this message
| Christian Ehrhardt (paelzer) wrote | #62 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Rafael,
thanks for giving it try. We knew it might be complex when we first saw the changes.
And I consider it wise to - at some point - step back and realize this won't be SRUable.
I'll summarize what we know about the libvirt portion of this:
## SRUability ##
The changes are rather complex, and will most likely not be SRUable.
Even if prepared for an upload they are massive and with a huge risk of regressing other use cases which we'd generally want to avoid.
I haven't done/tried the porting myself, but your doc reads fine and it grows and grows to become borderline to considering a major version bump which isn't an option here.
## How strict is the need for these ##
1. I know - after all I was a performance engineer for a decade - that speed is important. And those extra mitigation flags are all about improved mitigations for speed. But TBH, that also makes them not strictly required for the function.
2. After all the CPU features we are talking about here are still rare. You only get them at the very latest CPUs. So the chances that an existing server Farm needs those changes desperately are low. This will mostly be for consideration of new setups, and they can/should use the new code of the new release.
## Availability ##
1. The majority of this code is upstream in 5.5 and we backported it to 5.4 for Eoan - so there is a Ubuntu release that can use this code already.
2. LTS users in Bionic (way more than Eoan I'd think) can get also access to it via the Ubuntu Cloud Archive [1]. And that is not only true for the now released 5.4, but when we release Ubuntu 20.04 there will be a new UCA along it containing all the final upstream fixes (not only our backports) - and that will be supported for an even longer time.
## Verdict ##
I second your call on these patches after reading your summary, lets call the related libvirt backports Won't Fix for now.
## TODOs ##
@Rafael - do you still have a TODO on the kernel side as there are tasks open and assigned?
@Rafael - while I generally dislike raw qemu-cmdline in XML documenting an example as you suggested might be useful, will you come up with a draft for it?
@Rafael/Christian - lets also talk with the Team about it to get everyone on the same page.
[1]: https:/