Monthly gem5 Developers' Meeting - Oct 8th at 4pm (UTC)

[Harshil2107]

The monthly gem5 Developers' Meeting will take place on Oct 8th at 4pm UTC.

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

Agenda:

• gem5 release update (staging branch created) https://github.com/orgs/gem5/discussions/3560
• misc: Add thoughtful-code-review agent skill #3557

Metting Information:

Microsoft Teams meeting

Join:
https://teams.microsoft.com/meet/22763211090368?p=HVcd3McnCX8FkV7MIx

Meeting ID:
227 632 110 903 68

Passcode:
3MG9NS9A

[rajeshgangam]

Hi @Harshil2107

Thanks for the post.

Just checking if there is a possibility of a calendar invite for a mailing group, so I can keep track of the meeting and plan accordingly.
I have some ideas and want to discuss.

[Harshil2107]

Hi @rajeshgangam

Thanks for the suggestion! Going forward, I'll include a calendar file (.ics) in the GitHub discussion for each meeting, so you can import it directly into your calendar.

[BobbyRBruce]

Meeting recording

A recording of the October 8 meeting can be found at
https://youtu.be/hWVDG1qMbu8

Slides

Presentation slides (PPTX)

Meeting notes

These meeting notes are AI generated from the meeting recording and its
transcript, with the presentation slides used to check references.

gem5 v26.0 staging and release

• Bobby announced that official staging had started and
  release-staging-v26-0
  was available for community testing. The release process provides at least
  two weeks to test the staging branch before merging it into stable.
• The planned release date was Monday, October 19, 2026. Bobby clarified
  that staging could be extended if problems required more time; this was a
  target, rather than a guaranteed release date.
• Community members were encouraged to build staging and try their usual
  configurations and workloads. Those who could fix a bug should submit the
  fix to develop and notify Bobby that it was needed for the release. He would
  cherry-pick reviewed and merged fixes into staging.
• Staging was reserved for bug fixes and release-critical changes. New features
  could continue landing on develop for a subsequent release.
• See the staging announcement and testing instructions,
  release notes,
  and release PR #3559.

AI review skill and review bot (PR #3557)

• Jason presented PR #3557, which added
  the thoughtful-code-review skill. Its entry point referred reviewers to a
  review constitution and a performance-modeling checklist.
• The constitution encouraged reviewers to begin by assuming the author had
  a reason for the implementation and to substantiate concerns before raising
  them. The checklist covered functional correctness, simulator performance,
  and unexpected changes to the performance of the simulated system.
• Jason invited feedback on the skill and hoped to merge an initial version
  soon, then improve it through use. Connecting Copilot to the skill was a
  proposed next step; it had not yet been done.
• Separately, Jason described a gem5 review bot GitHub app and a Claude
  review process running on his local machine. It checked out a PR, used the
  skill to review it, and attempted to reproduce the reported problem on
  develop and verify the fix on the PR, including builds and reproducers.
  Jason had selectively posted its reviews; this was not yet an automatic
  review of every PR.

Community feedback on AI reviews and contributions

• Matt reported that repeated Copilot reviews sometimes found new issues after
  an author had addressed the previous round. Jason acknowledged the problem
  and said the proposed skill did not currently solve it. Possible improvements
  included emphasizing consequential findings and allowing a review to report
  no issues when none warranted a comment.
• Bobby asked for actionable fixes and inline suggested patches where the
  reviewer understood the solution. Jason thought the skill helped with this,
  while acknowledging that handling many valid findings could still burden
  contributors.
• Attendees who spoke found the reviews useful, but raised concerns about
  repeated notifications, iterative findings, and overlap between Copilot,
  Jason's bot, and the CI investigation workflows. Bobby preferred consolidated
  feedback over many separate pings. Jason identified avoiding comments that
  duplicated existing feedback as guidance to add to the skill.
• Bobby raised uncertainty about whether contributors had to address every
  Copilot comment to obtain approval. Jason said a human remained responsible
  for interpreting bot findings and deciding which needed attention.
• Jason invited feedback before expanding automation, including concerns about
  false positives and review volume. The discussion did not establish a new
  rule requiring authors to comply with every automated comment.
• Jason also reported more contributions from first-time and returning
  contributors, which he associated with increased AI use. AI-assisted PRs were
  being accepted through review. Bobby noted that automated reviews helped with
  the growing workload, but more human reviewers were still welcome.

Buenos Aires bootcamp

• A gem5 bootcamp was announced for November 24–28, 2026, in Buenos Aires,
  organized by Tamara Lehman. Jason clarified that it was not colocated with a
  conference.
• The bootcamp would use the previous year's materials, updated for changes
  since then. Further details were expected on the
  gem5 events page; people with questions could
  contact Tamara.

Chip-to-chip communication and chiplet modeling

• Carlos described his group's work on chip-to-chip communication modeling and
  asked whether an upstream contribution would be useful. He noted a previous
  community discussion and the possibility of coordinating with other groups.
• Jason welcomed the direction and encouraged checking existing discussions
  and PRs for related work. He suggested integrating it with the gem5 standard
  library, potentially representing each chiplet as a collection of processor,
  cache-hierarchy, and memory components connected on a board.
• The existing interfaces would likely need changes, and Jason was open to
  considering those changes to support research on systems with multiple
  chiplets.
• Bobby suggested sharing the work through a draft PR, an issue, or a future
  Developers' Meeting presentation. The group expressed interest in seeing the
  implementation; no specific design or merge decision was made.

Noncontiguous memory requests in O3 (PR #3587)

• Saul followed up on last month's discussion with
  PR #3587, introducing
  NonContiguousDataRequest. It provided a path for memory operations accessing
  addresses with holes, such as vector gather/scatter loads and stores, as an
  alternative to splitting them into separate contiguous micro-operations.
  Instructions did not yet use the new request type.
• Saul raised a modeling question for a possible follow-up: combining accesses
  could reduce their load/store queue occupancy from several entries to one.
  He asked whether an operation should be able to reserve multiple entries,
  potentially under a configurable model.
• Jason saw this as a broader issue in how O3 represents micro-operations and
  resource consumption, also relevant to x86. He supported exploring an
  interface that could describe an operation's resource requirements, while
  weighing modeling accuracy against implementation complexity.
• Saul described a small internal implementation that counted request fragments
  as queue entries, but said its accuracy against real hardware still needed
  assessment. Jason suggested Arm SVE as a useful comparison if suitable
  accuracy data became available.
• Saul considered opening a discussion on the resource-accounting idea. The
  meeting did not settle the accounting model or approve a particular refactor.

RISC-V vector-state modeling (issue #3472)

• Saul also followed up on last month's vsetvl discussion through
  issue #3472, proposing to move
  vl/vtype out of PCState and revisit modeling vector-configuration
  instructions as control flow.
• The proposed approach made vl a renameable data dependency and derived
  micro-operation expansion from vtype and EMUL, the effective register-group
  size, rather than the active vector length. The forms with immediate vtype
  could supply that information at decode; the register-supplied vtype form
  would need a slower path involving serialization or a squash.
• Saul pointed to related implementations in XiangShan hardware and its gem5
  fork. Jason supported pursuing the direction and noted that broader RVV
  implementation coverage should now make testing easier. He also cautioned
  that the fork's license needed checking before reusing code.
• The proposal was independent of the queue-resource accounting discussed
  earlier. Saul explained that expansion by EMUL could generate additional
  micro-operations when vl activated fewer registers, including operations
  with no active elements. Jason was comfortable with such modeling changes
  if they were clearly documented in the release notes.
• Saul planned to coordinate with the issue's author about the work, check the
  licensing, and post updates. No implementation was merged or finalized during
  the meeting.

Action items

• Community testers: exercise v26.0 staging, report problems, and contribute
  fixes where possible. Notify Bobby when a fix needs inclusion in the release.
• Bobby: cherry-pick reviewed and merged release fixes from develop into
  staging and reassess the October 19 target if blockers require more time.
• Community reviewers: provide feedback on PR misc: Add thoughtful-code-review agent skill #3557 and on the usefulness and
  burden of automated reviews.
• Jason: progress the review skill, consider connecting Copilot to it, and add
  guidance to avoid duplicating existing review comments.
• Carlos and his group: consider sharing the chip-to-chip implementation via a
  draft PR, issue, or future meeting presentation.
• Saul: consider a discussion on queue-resource accounting, and coordinate the
  issue [RFC] Move RISC-V vl/vtype out of PCState and stop modelling vset as a branch #3472 work with its author, including checking the license before
  reusing code.
• Harshil: announce the next Developers' Meeting through GitHub Discussions and
  the mailing list. The next meeting was confirmed for November 12, 2026.