pyapi: generate basic python bindings with PyO3

[Wenzel]

Generate (basic) python bindings to initialize libmicromi from Python, based on PyO3
fix #162

[codecov-io]

Codecov Report

Merging #165 (d4414ab) into master (cb49f1a) will decrease coverage by 0.18%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #165      +/-   ##
==========================================
- Coverage   14.80%   14.61%   -0.19%     
==========================================
  Files           5        5              
  Lines         466      472       +6     
  Branches       86       87       +1     
==========================================
  Hits           69       69              
- Misses        377      383       +6     
  Partials       20       20              

Flag	Coverage Δ
unittests	14.61% <0.00%> (-0.19%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/api.rs	0.00% <ø> (ø)
src/capi.rs	0.00% <0.00%> (ø)
src/driver/kvm.rs	23.20% <0.00%> (-0.16%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cb49f1a...d4414ab. Read the comment docs.

[Wenzel]

So I managed to expose the DriverType and DriverInitParam types to Python.

It might not be the best way, but it works

There is an opened issue on PyO3 to discuss how they should implement and expose Rust enum to Python.
Maybe in the future we could remove this code and let it managed by PyO3.

[Wenzel]

Note: I had to remove the conditional compilation in DriverType:
https://github.com/Wenzel/libmicrovmi/pull/165/files#diff-adea2445327e39eb215de697b440dbbc02135357380fb612a10a9e659129a46bL25

But this is what we wanted with #151 anyway, so i will rebase once this other PR merged.

[Wenzel]

library init works (here on Xen), but read_physical implementation returns an empty List (?)

[Wenzel]

Ok, so, this implementation is not working:

        let mut buffer = Vec::with_capacity(size);
        self.driver.read_physical(paddr, &mut buffer).map_err(PyMicrovmiError::from)?;
        debug!("buffer = {:?}", buffer);

but this one is:

        let mut buffer2: [u8; 1024] = [0; 1024];
        self.driver.read_physical(paddr, &mut buffer2).map_err(PyMicrovmiError::from)?;
        debug!("buffer2 = {:?}", buffer2);

Why I can't manage to fill my vector and return it ?

[Wenzel]

Ok, so the catch was that Vec::with_capacity was creating an empty vec, so the array had a size of 0 🤡

This is fixed now.

[Wenzel]

@rageagainsthepc i fixed another bug in the Xen read implementation :)
we were not reading correctly when the request was inside a page, and not just right a the beginning of it:
d4c417e

buf[buf_start..buf_end].copy_from_slice(&page[page_start..page_end]);

⬆️ page_start offset is new

it's fixed now, and volatility works