Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor vmm builder code to simplify logic that creates the microVM to boot #4547

Open
bchalios opened this issue Apr 9, 2024 · 4 comments
Labels
Good first issue Indicates a good issue for first-time contributors Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` Status: WIP Indicates that an issue is currently being worked on or triaged

Comments

@bchalios
Copy link
Contributor

bchalios commented Apr 9, 2024

Description

Currently, the logic to create a Vmm object is scattered across vmm/lib.rs and vmm.builder.rs files and it is quite convoluted and some times difficult to follow. Moreover, there is a lot of architecture specific code inserted in arbitrary places which further increases the un-readability.

Apart from the aesthetics and readability aspect, the state of the code makes it quite difficult to unit test. There are functions that take 7 arguments just to pass them (way) down the stack. That makes unit-testing very hard, since we often need to construct dummy versions of objects (like EventManager) even though they are not used in the part of the code we are trying to test.

Solution

Re-work the vmm construction code to simplify code paths and isolate architecture-specific code.

@roypat roypat added Good first issue Indicates a good issue for first-time contributors Status: Parked Indicates that an issues or pull request will be revisited later labels Aug 12, 2024
@tommady
Copy link
Contributor

tommady commented Oct 25, 2024

Hi, may I take this task to practice?

@tommady
Copy link
Contributor

tommady commented Nov 13, 2024

Hi @bchalios
in the current main branch

the logic to create a Vmm object is scattered across vmm/lib.rs and vmm.builder.rs files

I don’t see any Vmm object returned in the vmm/lib.rs file. Please let me know if I’ve misunderstood.

since we often need to construct dummy versions of objects (like EventManager) even though they are not used in the part of the code we are trying to test.

Could you point me to an example of this? Or are you referring to

event_manager = EventManager::new() 

as the so-called dummy version?
and in the create_vmm_and_vcpus function, for instance, event_manager is passed to allow subscription to serial_device. This makes it unclear why event_manager could be omitted.

Could you share your thoughts on how you would approach avoiding the need to pass event_manager, as you mentioned?

After all, may I ask why the create_vmm_and_vcpus function is specified only for aarch64? It seems to be used in several places, even with x86_64.

Otherwise, I completely agree with your points and will work on addressing them.

thanks.

@tommady
Copy link
Contributor

tommady commented Nov 14, 2024

I just found this #4411
seems related

@tommady
Copy link
Contributor

tommady commented Nov 15, 2024

Hi @bchalios @roypat
I tried to let the architecture-specific cfg contained in

  1. build_microvm_for_boot
  2. build_microvm_from_snapshot

Kindly review the PR at your convenience.
Thank you!

@Manciukic Manciukic added Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` Status: WIP Indicates that an issue is currently being worked on or triaged and removed Status: Parked Indicates that an issues or pull request will be revisited later labels Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Indicates a good issue for first-time contributors Priority: Low Indicates that an issue or pull request should be resolved behind issues or pull requests labelled ` Status: WIP Indicates that an issue is currently being worked on or triaged
Projects
None yet
Development

No branches or pull requests

4 participants