This will allow dkms to skip u2mfn module install if one is already
shipped with the kernel package - which is the case for kernels
delivered through dom0.
Make the version high enough to be considered newer than dkms package.
Sadly, it does not prevent module build. And the build fails becaue of
mismatching compiler version (kernel headers include gcc plugins).
Skip the build by setting BUILD_EXCLUSIVE_KERNEL in dkms.conf. Ideally,
we'd set some value indicating "don't build on kernel *qubes*", but
this variable does not support negation. So, set this variable to a
dummy value after manually checking $kernelver variable.
FixesQubesOS/qubes-issues#4963
Before this commit u2mfn got the address via kmap(get_user_pages(...)).
This has the problem that get_user_pages() does not work in some cases.
For example when qemu in a stubdom tries to get the mfn for a page which
is mapped from the target domain u2mfn fails because get_user_pages()
cannot be used for such mappings.
So get the address from the pte with apply_to_page_range(). Since we are
only interested in one page get_locked_pte() would be simpler but it's
not available to modules.
The module is required by gui-agent, so make sure it will be actually
installed. This would also install the module in dom0 (when
qubes-kernel-vm-support is installed there), but this this is harmless.
QubesOS/qubes-issues#1354
At the moment, Xen has a 16TB limit on x86, so this has no practical
impact, aside for silencing compiler truncation warnings.
Also, the rest of the GUI/u2mfn code and protocol would need to be
expanded to use 64-bit mfns for Qubes to actually work there.
This is preparation for pvgrub support, where all VM kernel files will
be installed inside of VM instead of dom0.
But also the same could be used to prepare VM kernel image from any dom0
kernel.
