It appears that the PCI BAR memory is slow to access with remap_pfn_range
and that it should instead be faulted in one page at a time.
The commit 5774e21965 implemented the former
behaviour and caused a performance regression in the VM->VM case.
This commit retores the old behaviour, but extends it to support mmaping
the kvmfr device directly, without going through a dmabuf.
This commit makes the test program try the following cases:
* mmaping 0-offset dmabuf with 0 offset
* mmaping 0-offset dmabuf with 1 page offset
* mmaping page-offset dmabuf with 0 offset
* mmaping page-offset dmabuf with 1 page offset
* mmaping device with 0 offset
* mmaping device with 1 page offset
This allows PCI kvmfr devices to be directly mmap'd just like in-memory
ones. Also, the more efficient mmap implementation is used for mapping
the dmabuf, avoiding the faulting code entirely.
Added an array option static_size_mb to the kvmfr module to create a
list of in-memory kvmfr devices. These devices support dmabuf just like
normal kvmfr devices. Additionally, they can be mmap'd, which allows
them to be passed to qemu as ivshmem devices.
This makes it a compile-time error to call a function that semantically
takes no parameters with a nonzero number of arguments.
Previously, such code would still compile, but risk blowing up the stack
if a compiler chose to use something other than caller-cleanup calling
conventions.
1) With the change to the Makefile, this update allows dkms to build and install the module for different kernels.
2) As per dkms documentation, no use of ${dkms_tree}.
3) Removed the use of REMAKE_INITRD as this module is not needed that early in the boot process.
4) Updated version to match what's defined in the module
