[RFC] Bareflank-LibVMI Hypercall ABI about libvmi_extensions

[boddumanohar]

My first idea was to use the register to exchange data. But in cases where I would like to know the state of all the registers, I cannot use the registers. And in some cases size of the data could be more than 64 bits. For this reason, I choose to exchange data in the memory. In memory, using structs could lead to some problems with compiler vecause we use different compiler for Bareflank(clang) and LibVMI(gcc). So I thought an other structured way to exchange data would be JSON.

[rianquinn]

The shared memory buffer makes sense, but the rule of thumb should be, if it can fit in the registers, use the registers, if it doesn't fit in the registers, use a shared memory region, and define the data via in a struct.

Also.... I would make sure that you don't use variable sized structures. Meaning, each struct that you need in the shared memory page should have a max size to improve safety, and allow you to keep the shared page mapped in at all times.

[rianquinn]

is there a particular reason why JSON is being used for the ABI? JSON works great when a human has to fill in the information. Since this is code your adding to LibVMI, it would be a lot easier if you created a register based ABI, and just filled in each register as needed.

[cjams]

Personally I've never been a fan of having a JSON parser run in VMX-root. IMO, the ABI should use the bare-minimum required, and then more complex actions like "map this memory and parse it as JSON" built on top of the register-based ABI.

Is this ABI specific to libVMI? Or will this form the basis of the the entire PV interface?

[boddumanohar]

[RFC] VMcall interface discusses a typical Bareflank hypercall ABI. The primary goal here is to exchange the kind of data that cannot simply fit into registers. So the Hypervisor should maintain a shared region to exchange such data. We create the shared region and provide the pointers to shared regions in the registers.

Along with that, this shared region could be used by memory mapping hypercalls. where we map a process's memory running in a guest VM into the shared memory so that libVMI can read mapped memory.

The PV interface will simply be an extension to the shared memory. PV interface should support interrupts too. So this shared memory + interrupts support together will be called as PV interface.

@rianquinn @connojd @tklengyel do you have any suggestion on how data in this shared memory has to be formated other than JSON?

[tklengyel]

I'm not in favor of using C structures in the shared memory region. Xen did that and if you ask anyone working with it will tell you that it was a mistake. Using json would probably make our life easier even if that means having to include a json library into the hypervisor.