Let the UART accept a whole buffer of u8, instead of single bytes only

[jounathaen]

At the moment, the output is sent byte-by-byte: https://github.com/hermitcore/libhermit-rs/blob/master/src/arch/x86_64/kernel/serial.rs#L25-L29
We could instead send the whole buffer at once and reduce the number of KVM exits this way.

[mkroening]

Do you want to do this in an additive fashion by adding another hypercall and then migrating slowly? Removing/Replacing a hypercall in a non-backwards-compatible manner requires a uhyve-abi version change and might best be done together with other changes.

[jounathaen]

No, we can simply add a new call.

[nathanwhyte]

Hi Jonathan,

I'm a Computer Science student at UT Austin and I'm taking a virtualization course. We've been assigned to contribute to open-source virtualization projects, so could I take a shot at resolving this issue?

[jounathaen]

Sure, go ahead! PRs are always welcome 🙂

[nathanwhyte]

@mkroening @jounathaen

A few questions:

Which of the functions causes the KVM exit?

Is it send() in serial.rs or is it the call to send within that, which calls write() from the x86_64 crate's port module?

How should I approach the change?

I noticed that the send/write functions being used currently only accept u8, not a buffer of u8, so I'm not sure how to go about sending a buffer.

[mkroening]

Which of the functions causes the KVM exit?

A KVM exit (context switch from guest to hypervisor) may happen due to different guest actions. In this case, x86_64 port I/O to a specific address triggers the KVM exit. This is done using assembly in the x86_64 crate port abstraction.

How should I approach the change?

While the action that triggers the KVM exit may not carry data of arbitrary length, it may point to a struct describing such data. So instead of a byte for output, it may point to a struct containing address and length of a byte sequence (imitating a slice).

While I am no expert in Uhyve hypercalls myself, the other hypercalls might be a good reference on passing more complex structs.

The technical details of how to integrate the new hypercall in the end depend on whether we can land #452 before. That PR of @jounathaen reworks the hypercall definitions and might also be a good starting point or source of information (though that PR is subject to change, as it is not merged yet).