Releases: oxidecomputer/hubris
Releases · oxidecomputer/hubris
gimlet release
net: wake all sockets on restart. This avoids a potential liveness issue described in #1844, wherein a task waiting for tx queue space would not notice net restarting. Fixes #1844.
sidecar release
Tech port unlocking (simple version) (#1835) This PR implements tech port unlocking, as described in [RFD 492](https://rfd.shared.oxide.computer/rfd/492). It corresponds to https://github.com/oxidecomputer/management-gateway-service/pull/259 and should be merged after that goes in. There's a lot going on here, but it's tricky to split into smaller PRs, so I'll describe the different moving pieces ## Changes to `net` VLANs ### Configuration VLANs are no longer contiguous; instead, the configuration in the manifest specifies them by VID. Each VLAN is also labelled as trusted or untrusted, which changes the behavior of the `net` task. The mapping from VLAN to port has become many-to-one, because Sidecar now has 3x VLANs on `SpPort::One`. ### Runtime behavior Packets to/from untrusted VLANs are dropped in the `net` task, unless the destination task has `accept-untrusted = true` in its socket configuration. This may be disabled for a limited time with the new `Net.trust_vlan` Idol API. ## Monorail and KSZ8463 configuration changes The VSC7448 (Monorail) and KSZ8463 switch have a new baseline configuration: packets between VSC7448 port 48 (to the Sidecar-local SP) and the KSZ8463 are now VLAN tagged per [this scheme](https://rfd.shared.oxide.computer/rfd/492#_fully_tagged_packets_on_port_48). In addition, the VSC7448 is now configured to disable access to SPs (other than the Sidecar-local SP) from the tech port. This is implemented in `configure_vlan_sidecar_locked`. The Monorail API now has two new functions (`Monorail.unlock_vlans` and `Monorail.lock_vlans`) to change this behavior. ## Changes to `control-plane-agent` ### General Across all boards, `SpImpl` function signatures and implementations are changed to use the new `Sender` type where appropriate. ### Sidecar On the Sidecar, we implement tech port unlocking based on a `Trivial` challenge, which calls into `monorail` and `net` to reconfigure them.
psc release
Tech port unlocking (simple version) (#1835) This PR implements tech port unlocking, as described in [RFD 492](https://rfd.shared.oxide.computer/rfd/492). It corresponds to https://github.com/oxidecomputer/management-gateway-service/pull/259 and should be merged after that goes in. There's a lot going on here, but it's tricky to split into smaller PRs, so I'll describe the different moving pieces ## Changes to `net` VLANs ### Configuration VLANs are no longer contiguous; instead, the configuration in the manifest specifies them by VID. Each VLAN is also labelled as trusted or untrusted, which changes the behavior of the `net` task. The mapping from VLAN to port has become many-to-one, because Sidecar now has 3x VLANs on `SpPort::One`. ### Runtime behavior Packets to/from untrusted VLANs are dropped in the `net` task, unless the destination task has `accept-untrusted = true` in its socket configuration. This may be disabled for a limited time with the new `Net.trust_vlan` Idol API. ## Monorail and KSZ8463 configuration changes The VSC7448 (Monorail) and KSZ8463 switch have a new baseline configuration: packets between VSC7448 port 48 (to the Sidecar-local SP) and the KSZ8463 are now VLAN tagged per [this scheme](https://rfd.shared.oxide.computer/rfd/492#_fully_tagged_packets_on_port_48). In addition, the VSC7448 is now configured to disable access to SPs (other than the Sidecar-local SP) from the tech port. This is implemented in `configure_vlan_sidecar_locked`. The Monorail API now has two new functions (`Monorail.unlock_vlans` and `Monorail.lock_vlans`) to change this behavior. ## Changes to `control-plane-agent` ### General Across all boards, `SpImpl` function signatures and implementations are changed to use the new `Sender` type where appropriate. ### Sidecar On the Sidecar, we implement tech port unlocking based on a `Trivial` challenge, which calls into `monorail` and `net` to reconfigure them.
rot release
Tech port unlocking (simple version) (#1835) This PR implements tech port unlocking, as described in [RFD 492](https://rfd.shared.oxide.computer/rfd/492). It corresponds to https://github.com/oxidecomputer/management-gateway-service/pull/259 and should be merged after that goes in. There's a lot going on here, but it's tricky to split into smaller PRs, so I'll describe the different moving pieces ## Changes to `net` VLANs ### Configuration VLANs are no longer contiguous; instead, the configuration in the manifest specifies them by VID. Each VLAN is also labelled as trusted or untrusted, which changes the behavior of the `net` task. The mapping from VLAN to port has become many-to-one, because Sidecar now has 3x VLANs on `SpPort::One`. ### Runtime behavior Packets to/from untrusted VLANs are dropped in the `net` task, unless the destination task has `accept-untrusted = true` in its socket configuration. This may be disabled for a limited time with the new `Net.trust_vlan` Idol API. ## Monorail and KSZ8463 configuration changes The VSC7448 (Monorail) and KSZ8463 switch have a new baseline configuration: packets between VSC7448 port 48 (to the Sidecar-local SP) and the KSZ8463 are now VLAN tagged per [this scheme](https://rfd.shared.oxide.computer/rfd/492#_fully_tagged_packets_on_port_48). In addition, the VSC7448 is now configured to disable access to SPs (other than the Sidecar-local SP) from the tech port. This is implemented in `configure_vlan_sidecar_locked`. The Monorail API now has two new functions (`Monorail.unlock_vlans` and `Monorail.lock_vlans`) to change this behavior. ## Changes to `control-plane-agent` ### General Across all boards, `SpImpl` function signatures and implementations are changed to use the new `Sender` type where appropriate. ### Sidecar On the Sidecar, we implement tech port unlocking based on a `Trivial` challenge, which calls into `monorail` and `net` to reconfigure them.
gimlet release
Tech port unlocking (simple version) (#1835) This PR implements tech port unlocking, as described in [RFD 492](https://rfd.shared.oxide.computer/rfd/492). It corresponds to https://github.com/oxidecomputer/management-gateway-service/pull/259 and should be merged after that goes in. There's a lot going on here, but it's tricky to split into smaller PRs, so I'll describe the different moving pieces ## Changes to `net` VLANs ### Configuration VLANs are no longer contiguous; instead, the configuration in the manifest specifies them by VID. Each VLAN is also labelled as trusted or untrusted, which changes the behavior of the `net` task. The mapping from VLAN to port has become many-to-one, because Sidecar now has 3x VLANs on `SpPort::One`. ### Runtime behavior Packets to/from untrusted VLANs are dropped in the `net` task, unless the destination task has `accept-untrusted = true` in its socket configuration. This may be disabled for a limited time with the new `Net.trust_vlan` Idol API. ## Monorail and KSZ8463 configuration changes The VSC7448 (Monorail) and KSZ8463 switch have a new baseline configuration: packets between VSC7448 port 48 (to the Sidecar-local SP) and the KSZ8463 are now VLAN tagged per [this scheme](https://rfd.shared.oxide.computer/rfd/492#_fully_tagged_packets_on_port_48). In addition, the VSC7448 is now configured to disable access to SPs (other than the Sidecar-local SP) from the tech port. This is implemented in `configure_vlan_sidecar_locked`. The Monorail API now has two new functions (`Monorail.unlock_vlans` and `Monorail.lock_vlans`) to change this behavior. ## Changes to `control-plane-agent` ### General Across all boards, `SpImpl` function signatures and implementations are changed to use the new `Sender` type where appropriate. ### Sidecar On the Sidecar, we implement tech port unlocking based on a `Trivial` challenge, which calls into `monorail` and `net` to reconfigure them.
sidecar release
Remove unconnected QSPI reset line (#1812) This is a legacy pin from the original Gemini Bringup Board, and isn't actually connected on Sidecar (PF5 is `V1P8_PG_A2`, which we're presumably fighting against)
psc release
Remove unconnected QSPI reset line (#1812) This is a legacy pin from the original Gemini Bringup Board, and isn't actually connected on Sidecar (PF5 is `V1P8_PG_A2`, which we're presumably fighting against)
rot release
Remove unconnected QSPI reset line (#1812) This is a legacy pin from the original Gemini Bringup Board, and isn't actually connected on Sidecar (PF5 is `V1P8_PG_A2`, which we're presumably fighting against)
gimlet release
Remove unconnected QSPI reset line (#1812) This is a legacy pin from the original Gemini Bringup Board, and isn't actually connected on Sidecar (PF5 is `V1P8_PG_A2`, which we're presumably fighting against)
sidecar release
Add a long timeout for setting boot component Setting the stage0 boot component involves writing to flash which requires a longer timeout