We should remember to credit Oracle for starting the Xen-on-KVM work. I did start from their old patch set, even if what got merged was significantly different in the end.
I do still want to flesh out the Xen guest support in Rust-VMM at some point.
Hah, I wondered why there was an uptick of attention to that old tweet.
We should be slightly careful — while I can't deny that there's a small element of "ITYS" about that tweet, should it really count if I then left it up to Intel to follow up?
I whined that we hadn't shown that it was safe. The credit really does need to go to the RETbleed folks who put in the work to truly demonstrate that it wasn't.
It's a big company, and I don't know how long ago your experience is or what your position was.
My experience, in my part of the company, in 2019, is that stuff I do outside "work" is my own business. I contribute to open source projects all over the place.
As long as I actually do my day job during the daytime, woe betide anyone (other than my wife and family) who tells me what I should be doing with my non-work hours, on unrelated software projects.
They even let me release my skunkworks Pidgin Linux client for Chime under LGPL (although I did have to ask permission for that one as I did a bunch of it during the day).
In fact even for work hours when I'm working on Linux, we've made progress. Once upon a time you had to file a ticket to legal for every patch series that was submitted upstream.
Now we have a policy (again, in our part of the company) that your internal code review submission must have a comment on the upstream status of your patch — is it already upstream, is it going upstream, and if not, WHY NOT?
And all you need in the way of permission to do so is to get the nod from myself or a number of other people right there in that code review.
Is it perfect?
No.
Do we still have to catch up and make it as easy for other projects (like Xen, in my day-to-day work) as it is for Linux?
Yes.
Is it a massive improvement on what it was like before?
Hell yes.
If I've been a moron in front of the whole world, you might as well call me one; that part doesn't make a lot of difference. And if I know I haven't, well it doesn't make a lot of difference if you call me one either. I'm not five years old any more, having to chant "sticks and stones may break my bones..." to convince myself it's true, choking back the tears.
There was no "pain" on reading the reply. Only a minor frustration that there had clearly been a miscommunication about the different parts of the patch series, leading to his objections when he saw something he didn't expect. And certainly no temptation to say what you suggest. It was a technical rant. No people were harmed, and a personal reply like that would have been completely unnecessary.
I was expecting him not to like IBRS. Hell, I don't like it either. But as I said later, it still wants posting in the light of day, and a conscious decision to drop it and accept the caveats, if that's what we're going to do.
Why would he do that? I completely agree with him on that, and I already told him I've been pushing back on it since I first heard about it a few weeks ago. Although there are technical reasons why we might need IBRS_ALL as a stop-gap before we can get to a proper solution, we bloody well ought to have line-of-sight to a proper solution in the same way that RDCL_NO says "it's OK, we fixed it" for Meltdown.
But that's a separate topic. As I explicitly said, I limited that answer to the things we can do on current hardware.
And could it be phrased differently as "EC2 doesn't do live migration badly"?