Hi Amy,
I don't think any of these justify a different approach than what we are
doing already.
On 21/10/21 04:24, Amy Parker wrote:
1. Supporting new hardware virtualization technologies, which may take
a while to develop but should still be available to users for testing
and non-production purposes while being refined, such as on new
architectures or by new manufacturers. It's entirely possible that
there will be new competitors in the x86_64 space soon, especially
with the increasing popularity of the concept of 128-bit computing
architectures.
The issue here would be, first and foremost, whether the architectures
would be supported by Linux. As KVM RISC-V is going to be included in
Linux 5.16, I'm not sure what other architectures would be supported by
Linux but only have experimental status in KVM.
In particular, the recent disagreements about including KVM for RISC-V
in some kind of "staging" code arose only after the architectural
specification had reached considerable stability, and so had the KVM code.
2. Experimental algorithms which optimize current functions; these may > not be immediately production-ready, but should be available to the
end user in something like the staging folder.
These are also not suitable for a separate staging subtree. Almost
always such optimizations require changes to existing code, in such a
way that the existing code needs to be aware of what the more
experimental code is doing.
It is okay to include experimental algorithms and optimizations before
they have reached feature parity with what they're supposed to replace.
See for example the "TDP MMU" code that has been contributed over the
past year and has only reached feature parity in 5.15.
3. Other future virtualization technologies, should they ever be
added, such as cross-binary architecture and syscall compatibility.
This is the same as the previous point: we have some code in Linux that
is not used widely (KVM for s390 has some microcode testing
functionality that is only used internally at IBM, and the Xen emulation
layer is only used by Amazon as far as I know), but it's okay to include
it if it's maintainable, reasonably mature, and covered by test cases.
However, contributions to KVM should follow the same quality standards
as the rest of Linux.
Thanks,
Paolo
