Why RISC-V doesn't yet support KVM
lwn.net
lwn.net
"""
And to be a bit more clear about this, having other subsystem maintainers drop their unwanted code on this subsystem, _without_ even asking me first is just not very nice. All of a sudden I am now responsible for this stuff, without me even being asked about it. Should I start throwing random drivers into the kvm subsystem for them to maintain because I don't want to? :)
If there's really no other way to do this, than to put it in staging, let's talk about it. But saying "this must go here" is not a conversation...
"""
I deeply cherish the fact this stuff is out in public. It helps more junior software devs learn the softer skills.
[1] https://lwn.net/ml/linux-kernel/YKTsyyVYsHVMQC+G@kroah.com/
always so humble, and dropping a ton of knowledge and advice. he really is the nice guy that his image projects.
I find this hard to reconcile with GregKH's current public image. :-)
perhaps when level 3 opens up, I'll make an appearance every once in a while!
I've never smoked, and at that point in time, I did not have long hair anymore (cut it off when I turned 30 which was before OSDL was ever started.)
Agreed, it makes me very happy to see some sanity in open source. In other projects like CPython, expect a little Twitter witch hunt by unproductive project politicians if you object to excessive changes.
Because of CPython's cultural revolution, the hierarchy is:
cabal
newcomers
productive long term developersPutting pressure on RISC-V to freeze the H-extension early would be IMHO a bad outcome if it's not frozen for a good reason. If it's not frozen for no known good reason and it's just vendors gaming the system then of course freezing it is a good idea, but that's quite an independent thing from linux.
However it's a bit of a chicken and egg situation, you need serious testing before you can ratify and freeze but if you don't encourage people to code against the (moving) spec you wont get the testing you need.
As a CPU designer it's particularly tough, wanting those changes frozen asap so you can implement them, but not wanting a broken one
Putting pressure on RISC-V would be Linux abusing its market position to interfere on RISC-V processes. This is particularly wrong to do, as RISC-V processes being open (unlike most other ISAs) shouldn't be seen as an invitation to discriminate against them by not allowing them the possibility of making incompatible changes.
The H extension is a little less clear cut as it doesn't affect user code (IIUC) and as such the damage is limited to OS kernelS (there's more than Linux out there).
However it's a slippery slope into fragmentation hell and I actually think the current policy is correct and the blame lies with the H committee.
EDIT: language
I have demonstrated that at least memcpy() can be be binary compatible between 0.7.1 and the current draft. I will check others soon (once I get a Nezha board, hopefully before the end of the month). Many other things could be made compatible -- most simple code using 16 or 32 bit int or 32 bit FP -- by reverting a single small commit to the spec in June 2020 which tidied up the bit field format of the VTYPE CSR but did not introduce any functionality.
There are things that are incompatible for very good reasons, but there is much that is either compatible now or that is incompatible for inessential reasons.
Reverting the format change in the SEW and LMUL fields, and making 0 for the mask agnostic and tail agnostic bits match the (fixed) settings in 0.7.1 would go a long way towards increasing compatibility, at virtually zero cost.
That staging is for sketchy drivers but this is architecture-specific code strikes me as especially silly. Never mind CPU vs peripheral: both are hardware with interfaces outside Linux's control. The important distinction is internal vs external interfaces, and staging makes sense for me for dealing with all sketchy external interfaces alike.
I still like Linux "helping out" RISC-V standardization by separating the unratified extensions --- traditionally the hardware is fait accompli and Linux is the agile software playing catch up but with something like RISC-V the roles are somewhat reversed --- but I fully grant that's separate to the purpose of staging as you say.
But this is all stuff you work out by looking at the finer points of the implementation and doing it in a way that does not encourage further divergence; certainly throwing stuff in staging isn't how you do it.
Ultimately, Linux's goal is to support the hardware; that support may be done in such a way to discourage future "bad" hardware, but it still has to be there as proper support, if the features have merit. For example, we have a patch series in review right now to support KVM on the M1, because (surprise surprise) Apple did some nonstandard stuff there too. It's definitely not going in staging though :)
On the other hand, it's less likely that mainline Linux will quickly gain support for, say, things like Apple's proprietary security features (their pointer auth extensions, paging protection stuff, etc) unless there are similar mechanisms implemented in other vendors' CPUs, because those things provide only marginal benefit for end users of specific systems, and Linux has bigger security fish to fry first.
If the code is likely to fail in weird ways for reasons that can't reliably be predicted or fixed ahead of time, I think it's fair to call it sketchy.
If the code uses instructions that might be defined out from under it, it's likely to fail in weird ways for reasons that can't reliably be predicted or fixed ahead of time.
No claim on whether it's a good idea (the "discourage bad hardware" angle would suggest not), but "staging is for sketchy drivers" at least seems consistent with including it.
They won't, though, at least not in a way that matters. Linux exists to make hardware run. There is hardware built against the current draft version of the H extension. KVM should be made to work on that hardware. If the final ratified H extension ends up having incompatible changes to what's there now, then that's just another revision that the kernel can support, just like Linux can support different features in different x86 generations.
If the hardware manufacturers were being reckless and shipping an earnestly-worked-on pre-standard before it was ready, I would perhaps agree that they shouldn't get mainline support.
But it seems the H extension has been sitting in limbo for a year now, and it seems the reason is that a company that is having trouble getting hardware ready for shipping is trying to stall the process so other companies don't have a leg up. That's not a good reason to punish these other (more competent?) companies by forcing them to carry out-of-tree patches. And given the situation, it's likely that the eventually-ratified version will be the same as (or at least compatible with) the current draft, so the risk of taking the code now and having to maintain compatibility hacks later is pretty low.
There will be always new HW designed which works differently to the old one. This goes for all types of HW. They never stop.
"There comes a time in every project when you must shoot the engineers and begin production.”
The staging approach would sound reasonable on the surface, until you realize the Linux staging subsystem is more specific[1] than the name implies, and not just a dumping ground for stuff that can’t be merged for other reasons.