build neuron kmod in kernel packages #207
Conversation
| %install | ||
| %kmake %{?_smp_mflags} headers_install | ||
| %kmake %{?_smp_mflags} modules_install | ||
|
|
||
| %if "%{_cross_arch}" == "x86_64" |
There was a problem hiding this comment.
Should we track somewhere when Neuron supports ARM?
There was a problem hiding this comment.
Should we track somewhere when Neuron supports ARM?
I don't think so. If EC2 ever launches an instance type that combines Neuron and Graviton, we can remove the conditional.
| @@ -42,6 +48,11 @@ Requires: %{_cross_os}microcode-licenses | |||
| Requires: %{name}-modules = %{version}-%{release} | |||
| Requires: %{name}-devel = %{version}-%{release} | |||
|
|
|||
| # Pull in platform-dependent modules. | |||
| %if "%{_cross_arch}" == "x86_64" | |||
| Requires: (%{name}-modules-neuron if (%{_cross_os}variant-platform(aws) without %{_cross_os}variant-flavor(nvidia))) | |||
There was a problem hiding this comment.
Should this be more restrictive, or is it OK to get the Neuron kernel module in FIPS variants?
There was a problem hiding this comment.
Should this be more restrictive, or is it OK to get the Neuron kernel module in FIPS variants?
Unlike NVIDIA, Neuron doesn't provide a PKCS#11 interface to userspace, so it seems fine to include it on FIPS variants.
| Requires: %{name} | ||
| Requires: %{_cross_os}ghostdog | ||
| Requires: %{_cross_os}variant-platform(aws) | ||
| Conflicts: %{_cross_os}variant-flavor(nvidia) |
There was a problem hiding this comment.
Is there an actual conflict with these two or is this just using the Conflicts to get the right experience where -nvidia variants won't include this driver but the rest will?
There was a problem hiding this comment.
Is there an actual conflict with these two or is this just using the Conflicts to get the right experience where -nvidia variants won't include this driver but the rest will?
I'm using the Conflicts here to indicate a license level conflict; the intent is to enforce that images only end up with one or the other. It's not required to have the right thing happen for the downstream variants in bottlerocket-os/bottlerocket.
Add public and internal functions to call `lspci` and look for Neuron devices in the output. Signed-off-by: Ben Cressey <bcressey@amazon.com>
Similar to the existing "efa-present" subcommand, this provides a CLI interface to look for Neuron devices and return success if found, and failure otherwise. This can be used as an ExecCondition in a systemd unit. Signed-off-by: Ben Cressey <bcressey@amazon.com>
Build the external Neuron kmod as part of the kernel build, so it can be signed with the ephemeral module signing key. That allows it to be loaded at runtime when kernel lockdown is in effect. Since autoload doesn't work for this module, add a custom instance of the modprobe unit that only runs if Neuron hardware is detected, and run it as part of sysinit.target. Signed-off-by: Ben Cressey <bcressey@amazon.com>
The Neuron driver is now built as part of the other kernel builds. Signed-off-by: Ben Cressey <bcressey@amazon.com>
bcressey
force-pushed
the
neuron-merge
branch
from
029d4ae
to
acc3b6a
Compare
|
⬆️ force push:
|
Issue number:
Related: bottlerocket-os/bottlerocket#4218
Description of changes:
Build the Neuron kmod as part of each kernel build, so that it can be signed with the ephemeral module signing key.
Testing done:
Verified that the Neuron module was auto-loaded on
inf1,inf2, andtrn1instance types, for each of the three kernels (5.10, 5.15, 6.1).On instance types without Neuron hardware, the module load was skipped and subsequent service starts were suppressed:
Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.