Babis Chalios

Hi Volker, Thanks for reporting this. We will take a look and reproduce it, but in the meantime I'd like to point out that this configuration: > Guest kernel: 5.19.8...

Also, to answer your question: > So to summarize, is the described behavior with deflate_on_oom=true a bug in the implementation or have I misunderstood the behavior of the ballooning device...

Hi @DavidVentura, I wanted to comment on this: > I'm using vmm as a crate to launch multiple VMs on the same process, and they all have un-synchronized access to...

Hey @DavidVentura, really sorry for the late response. Thanks for confirming my understanding. Given that your use-case is not something we want to support (quite the contrary), I don't think...

@DavidVentura I will close this PR now. Feel free to re-open this if you think there is more to discuss in the future

This is in a much better state now. Things that I still want to do is: 1. Add unit-tests for the newly introduced code. 2. Check if we really need...

Thanks for your review Egor! I think your comments make sense. Let me write what my thinking was behind the design choices. > * Combining allocators for different resources into...

> I haven't explored the idea throughout, but what if we combine all "device managers" (`pio_device_manager`, `mmio_device_manager`, `acpi_device_manager`) into 1 `DeviceManager`? This way it can contain all resource allocators and...

Changes from v1 to v2: * Re-worked the logic that writes the tables to guest memory. The functions taking care of that are not members of the `Vmm` type any...

Changes from v2 to v3: * Fixed aarch64 build error which was introduced in v2 due to importing of `acpi` module. This needs to be behind a feature gate (x86...