Monthly gem5 Developers' Meeting - February 13th at 5pm (UTC)

[Harshil2107]

The monthly gem5 Developers' Meeting will take place on February 13th at 5pm UTC.

If you would like to add anything to the agenda please create a comment below.

Agenda:

• Discussing the upcoming 24.1.1 minor release.
• sim-se: Implement free-list-based physical page allocator for SE mode #1825
• Simulating an ARM multicore system with more than 8 cores #1757
• AI generated code policy

Meeting link
Microsoft Teams Need help?
Join the meeting now
Meeting ID: 240 053 709 606
Passcode: PD6Cw7zf

[jonathanhaley]

It may also be worth discussing the gem5 project's policy on using AI generated code / Large Language Models in general. Are commits using generated code allowed at all, should they feature a tag specifying the use of AI etc...

[Harshil2107]

We’d be happy to discuss this if you have specific questions or points to bring up. If you’re able to join the meeting, we can allocate some time for it.

[BobbyRBruce]

Generated by AI. Be sure to check for accuracy.

Meeting notes:

• Minor Release of gem5: Bobby announced a minor release of gem5 by the end of next week, which will include a refactoring of the gem5 exit events. This update aims to provide more flexibility and richer disk images, allowing users to create and handle various exit events more easily.
  • Release Announcement: Bobby announced that a minor release of gem5 is expected by the end of next week. This release will include a refactoring of the gem5 exit events to provide more flexibility and richer disk images.
  • Exit Events Refactoring: The refactoring will allow users to create and handle various exit events more easily, enhancing the simulation process. This includes the ability to trigger exit events inside disk images at key events and handle them accordingly.
  • Backward Compatibility: Jason emphasized that the new exit events system will be fully backward compatible with the old exit events, ensuring that existing scripts will continue to work without modification.
  • API Changes: There was a discussion about potential changes to the API for handling exit events, with Jason suggesting improvements to avoid users having to remember arbitrary numbers for exit events.
• Exit Events Refactoring: Bobby explained the refactoring of exit events in gem5, highlighting the ability to create and handle a variety of exit events. This will enable users to have more control over their benchmarks and workloads, making the simulation process more flexible and efficient.
  • Exit Events Flexibility: Bobby detailed the new flexibility in creating and handling exit events, allowing users to define and manage a wide range of exit events tailored to their specific needs.
  • Implementation Details: Bobby provided a demonstration of the new exit events system, showing how users can use hypercalls to trigger exit events and handle them within their benchmarks and workloads.
  • Example Use Cases: Bobby shared examples of how the new exit events can be used, such as triggering events when the kernel stops booting or when a script starts and ends, providing more detailed control over the simulation process.
  • API and Hypercalls: The new system uses hypercalls to pass integers to the gem5 simulator, which are then mapped onto exit event types. This allows for a more flexible and extensible way to handle exit events.
  • Future Improvements: There was a discussion about potential improvements to the API, with Jason suggesting a better way to manage exit event IDs to avoid confusion and ensure ease of use.
• Governance Model and Communication: Giacomo raised concerns about the governance model and communication within the gem5 project, emphasizing the need for better communication and involvement of maintainers in decision-making processes. Jason and Bobby acknowledged the issue and agreed to discuss it further in the next meeting.
  • Governance Concerns: Giacomo expressed concerns about the current governance model and the lack of communication and involvement of maintainers in decision-making processes, suggesting the need for a more democratic approach.
  • Response from Jason: Jason acknowledged the concerns and agreed that the current governance model, which is meritocratic, may not be ideal. He suggested revisiting the governance model to ensure better communication and involvement of all maintainers.
  • Future Discussion: It was agreed that a broader discussion on the governance model and communication within the gem5 project would be held in the next meeting to address these concerns and find a suitable solution.
• Page Allocation in SE Mode: Harshil brought up a discussion about a PR related to page allocation in SE mode. Giacomo and Jason agreed that when someone calls reset stats, all stats should be reset to avoid confusion and ensure consistency.
  • PR Discussion: Harshil introduced a PR related to page allocation in SE mode, highlighting a change in how allocated bytes are computed.
  • Reset Stats Behavior: Giacomo and Jason discussed the behavior of the reset stats function, agreeing that all stats should be reset when the function is called to avoid confusion and ensure consistency in the simulation results.
• Running ARM Simulation with KVM: Harshil and Giacomo discussed the possibility of running ARM simulations with KVM in a model with more than 8 cores. Giacomo suggested using the GIC V3 machine and provided debugging tips to address any issues.
  • ARM Simulation with KVM: Harshil raised a question about running ARM simulations with KVM in a model with more than 8 cores. Giacomo confirmed that it is possible using the GIC V3 machine.
  • Debugging Tips: Giacomo provided debugging tips, such as using early print K as a kernel parameter and checking for warnings from the KVM APIs, to help address any issues encountered during the simulation.
• AI-Generated Code Policy: Harshil initiated a discussion on the policy for AI-generated code in commits. Jason and Bobby agreed that it is up to the committer to ensure they have the copyright for the code, and it would be polite to mention if a significant portion of the code is AI-generated.
  • AI-Generated Code: Harshil brought up the topic of AI-generated code in commits, questioning whether such code should be allowed and if it should be tagged as AI-generated.
  • Committer Responsibility: Jason and Bobby agreed that it is the responsibility of the committer to ensure they have the copyright for any code they submit, including AI-generated code.
  • Politeness in Tagging: It was suggested that it would be polite to mention if a significant portion of the code in a commit is AI-generated, to help maintainers review the code more effectively.

Follow-up tasks:

• Governance Model Discussion: Schedule a discussion for the next meeting to address the governance model and communication issues within the gem5 project. (Jason, Giacomo)
• KVM on ARM Debugging: Upload a script that demonstrates the issue with running gem5's KVM on ARM with more than 8 cores for further debugging. (Jason)
• KVM on ARM Debugging: Provide more information about the setup and issue encountered when running gem5's KVM on ARM with more than 8 cores. (Jason)
• AI-Generated Code Policy: Draft a note or guideline suggesting that contributors mention if their commits include AI-generated code, especially for complex contributions. (Bobby)