You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RFD 505 proposes that instances should be able to set a "minimum
hardware platform" or "minimum CPU platform" that allows uers to
constrain an instance to run on sleds that have a specific set of CPU
features available. Previously, actually-available CPU information was
plumbed from sleds to Nexus. This actually adds a `min_cpu_platform`
setting for instance creation and uses it to drive selection of guest
CPUID leaves.
As-is, this moves VMs on Gimlets away from the byhve-default CPUID
leaves (which are effectively "host CPUID information, but features that
are not or cannot be virtualized are masked out"), instead using the
specific CPUID information set out in RFD 505.
There is no provision for Turin yet, which instead gets CPUID leaves
that look like Milan. Adding a set of CPUID information to advertise for
an `amd_turin` CPU platform, from here, is fairly straightforward.
This does not have a mechanism to enforce specific CPU platform use or
disuse, either in a silo or rack-wide. One could imagine a simple system
oriented around "this silo is permitted to specify these minimum CPU
platforms", but that leaves uncomfortable issues like: if a silo A
permits only Milan, and silo B permits Milan and Turin, all Milan CPUs
are allocated already, and someone is attemting to create a new
Milan-based VM in silo A, should this succeed using Turin CPUs
potentially starving silo B?
0 commit comments