Mathieu Tarral

> 1. What do you mean by "libmicovmi HyperDBG driver"? Is it a custom driver that wants to interact with HyperDbg driver and libmicrovmi? I suppose I shouldn't have used...

Hi Sina, sorry for the lack of reply, i have been busy with other PRs. first, i wish you a happy new year 2021 :) > Let's give an example,...

That's a good idea, there is no rush, and we still working on other integrations here, like a Volatility3 address space for example

Indeed, good catch. Then we keep this API in the trait, and leave it unimplemented for KVM. The Libvmi Xen driver doesn't actually use the function in the driver implementation:...

An idea to allow each driver to describe what possible initialization parameters it can take: `api.rs` ~~~rust /// Describe a driver initialization parameter #[derive(Debug)] pub struct DriverInitParamDesc { name: String,...

I like enums because their a give a strong type definition instead of a losely defined string that wouldn't be checked at compile-time. However, it would be difficilt to express...

Update: the memflow connector_args could be rewritten with a more expressive enum like this: ~~~rust pub enum MemflowConnectorParams { // optional vm_name, otherwise will search for the first QEMU process...

Update, thinking again on your proposal, to reflect the possibility of passing mutiple initialization parameters for multiple drivers: ~~~rust use std::path::PathBuf; /// Describes Xen initialization parameters pub enum XenInitParams {...

Update: we can pack the common parameters inside the `MicrovmiInitParams` struct: ~~~rust use std::error::Error; use std::path::PathBuf; pub enum DriverType {} pub fn init_driver( driver_type: Option, driver_init_params: Option, ) -> Result...

This PR brings singlestep support for Xen, and implements the `reply_event` method, which was missing. I'm still having an issue to listen on multiple VCPU, I only receive events from...