Open olivierpierre opened 6 years ago
Hello Pierre,
you are right. I will create patch to solve this issue.
Best
Stefan
@olivierpierre: I got to know about your problem, however not about your proposed solution. Anyway, I've committed a fix for HermitCore-rs (the Rust implementation of HermitCore), which lets uhyve perform the virtual-to-physical address translation for the buffers of read/write operations. This way, the physical memory addresses of the buffer pages can be arbitrary.
The fix commit is https://github.com/hermitcore/hermit-caves/commit/6b9e4be0dc4ad65411e87c674e38138cd215c47e and seems to have also been merged to the HermitCore C version in the meantime.
@olivierpierre : Since yesterday I added a patch to the C version (see pull request 97). Could you test it on your system? By the way, I add also gdb support for aarch64...
@ColinFinck: I believe my initial post includes a description of the problem as well as two sample programs that trigger the issue. Please let me know if you need something specific.
@stlankes: thank! I will try the patch on our version and let you know
Hello,
With Uhyve, when performing file read/write operations in the host, the target buffer is fully read or written from the guest physical memory. Such a design assumes that the buffer is contiguous in physical memory, which is not always the case. When using a buffer allocated with
malloc
, example of bad things that can happen are:You can confirm these issues with these two sample programs and the corresponding Makefile:
Here is my proposed solution: a patch that forces the file read and write operations to be performed on a page-by-page basis, i.e. Uhyve file read or write operation is called for each page composing the buffer. I did not extensively tested it, nor did I evaluated the performance impact (I guess it slows things down a bit).