[haiku-development] Re: Regarding the KVM support
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 24 Jan 2020 19:17:28 +0000
While I appreciate the enthusiasm Laasya, I believe a Haiku project
related to KVM, NVMM or HAXM would be extremely advanced and probably
even difficult for long-time Haiku developers. I don't think it is
appropriate for GSoC. I think sometimes we propose projects we would
like to see done for GSoC because no one else has done them, and many
times the reason no one else has done them is because they are really
hard. I think this is one such project, as well as the one for
graphical acceleration.
Looking into the kernel-side code of NVMM, I find that it is not *that*
complex. What I understand about NVMM is that it does as much of the work
as possible in userland. We should be able to reuse the userland code
as-is, therefore a lot less work is needed.
https://nxr.netbsd.org/xref/src/sys/dev/nvmm/
Someday we'll manage to get people to stop thinking that kernel side
coding is super complicated black magic.
So, what do we have here? It's a driver with 15 ioctls (or 15 functions,
if you wish). There are two implementations of it (for AMD and Intel CPUs),
both about 3000 lines long. Surely, porting one of these to Haiku sounds
within reach to me.
Sure, it will probably uncover more problems. This code is designed to
work with the NetBSD kernel, and not everything it depends on will have
direct replacements in Haiku. So we will need either changes to the
ported code, or improvements to Haiku to add the missing functionalities.
So, if you want to work on this, that's great. As a GSoC proposal, I would
then expect an analysis of this code and what it depends on, in order
to have an idea of what's missing in Haiku to get it running. Then, we
would see if it can reasonably be done in 3 months, or if it seems better
to focus on implementing one or more of the needed kernel APIs.
--
Adrien.
Other related posts:
