Create unit tests for hypercalls

[n0toose]

I'm currently working on benchmarks that directly invoke hypercalls (without the presence of a UhyveVm, so as to measure "pure" performance without a vCPU and a VM). This method could be reused again to verify that hypercalls work as expected, as we test functions like virt_to_phys but not whether the libc:: functions we invoke to interact with the filesystem of a target operating system work as expected - we only use integration tests for those, which only run on an Ubuntu host, are computationally heavy and make it harder to spot regressions.

Currently, my very rough proof of concept - which is how a unit test could look like - looks somewhat like this:

// let mem = MmapMemory::new
// let flags = ...
// let mode = ...
initialize_pagetables(unsafe { mem.as_slice_mut() }.try_into().unwrap());
let filename = filename_string.as_bytes_with_nul().to_vec();
unsafe {
	mem.as_slice_mut()[MIN_PHYSMEM_SIZE + 0x00] = name[0];
        // [...] This is a dirty proof of concept.
	mem.as_slice_mut()[MIN_PHYSMEM_SIZE + 0x0a] = name[
}
let mut slice = unsafe{mem.as_slice_mut()}.to_vec();
uhyvelib::hypercall::open(&mem, &mut OpenParams {
	name: GuestPhysAddr::new(MIN_PHYSMEM_SIZE as u64),
	mode: mode,
	flags: flags,
	ret: ret,
});

[n0toose]

I am considering the option of creating a uhyve-utilities crate for components shared between unit tests, integration tests and benchmarks - which are "meta" and do not belong in Uhyve, the software.

I believe that doing so would bring massive benefits by minimizing code duplication and making it easier for changes in our benchmarks to have benefits for our testing too. Anyways, I opened this issue because this is not a priority at this very second and don't want to forget.

[jounathaen]

Currently, my very rough proof of concept - which is how a unit test could look like - looks somewhat like this:

I don't really get what you want to achive. The code snippet looks like a good unit-test for the hypercall::open function. Which additional functionality do you need?

I am considering the option of creating a uhyve-utilities crate for components shared between unit tests, integration tests and benchmarks - which are "meta" and do not belong in Uhyve, the software.

I'm also adding functionality that is only required for tests (c9ab783 - not merged yet). But I think it is sufficient to feature gate them with #[cfg(test)]. Maybe we can create a test-only mod, but a separate crate sounds a little overcomplicated.

[n0toose]

Hm, let's just implement tests first, see how much code we reuse and how we do it, and then make an informed decision on how to adapt the codebase so as to reduce reuse. Let's just go with that.

[jounathaen]

Then I'll close this issue?

[n0toose]

I think the best time to close it is when the unit tests are implemented? I think I slightly derailed the conversation by talking about the "how".