Mark unsupported VPD commands as Illegal - #38
Merged
Conversation
Based on some testing I did on a Cosmo in the lab, there are a variety
of VPD-related `MFR_$whatever` and `IC_DEVICE_{ID, REV}` commands that
various devices dislike. See [this comment][1] for details.
To prevent them from NACKing us and setting `STATUS_CML` a bunch, and to
better support the codegen changes I'm working on in
oxidecomputer/hubris#2650, this commit updates the config files for
those devices to mark the commands they find distasteful as `Illegal`.
[1]:
oxidecomputer/hubris#2650 (comment)
jamesmunns
approved these changes
Aug 28, 2026
jamesmunns
left a comment
jamesmunns
left a comment
Contributor
There was a problem hiding this comment.
Oooooooh, this feels illegal.
hawkw
added a commit
to oxidecomputer/management-gateway-service
that referenced
this pull request
Sep 4, 2026
Closes #435 (which this obsoletes). This branch adds a new `component-get-vpd` RPC that allows MGS to read the vital product data (VPD) for the requested SP component. The SP components that have VPD advertise this property via the `HAS_VPD` capabilities bit. The wire types allow reading a few different kinds of VPD: - A variety of PMBus commands for PMBus devices. Hubris will determine which of the commands a given PMBus device supports based on oxidecomputer/pmbus#38 and oxidecomputer/pmbus#39. This is potentially quite large, but usually isn't, based on what the device actually supports. - An Oxide barcode from a VPD EEPROM, which may be in either the 0XV1, 0XV2, or MPN1 formats as defined in [RFD 308]. - A Gimlet or Cosmo fan tray EEPROM, which contains barcodes for the fan tray assembly, the VPD board, and each individual fan on the assembly. - A TMP117 temperature sensor's little EEPROM thingy. The way this all works is designed to allow Hubris to avoid constructing these on the stack. In particular, the fan tray VPD may be "up to 640 bytes or more", given that the only real length limit on the MPN1 barcodes is that the whole thing will not be in excess of 128 bytes, and we may have a fan tray whose EEPROM contains five MPN1 barcodes, which is a lot. The PMBus VPD is also Not Small. Therefore, all the wire types are designed in such a way so that Hubris can read data _into_ a single scratch instance of the wire type which lives in a static, and then serialize from that straight into the trailing data of a response. This felt like the best compromise between wanting to use `hubpack` for serialization and not building really giant structs on the stack in `control-plane-agent`. This all probably makes a bit more sense if you also read the corresponding Hubris PR oxidecomputer/hubris#2650. [RFD 308]: https://rfd.shared.oxide.computer/rfd/0308
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on some testing I did on a Cosmo in the lab, there are a variety of VPD-related
MFR_$whateverandIC_DEVICE_{ID, REV}commands that various devices dislike. See this comment for details.To prevent them from NACKing us and setting
STATUS_CMLa bunch, and to better support the codegen changes I'm working on in oxidecomputer/hubris#2650, this commit updates the config files for those devices to mark the commands they find distasteful asIllegal.