This creates a more centralized way for nvproxy to return errors to the the
user mode driver via the NvStatus field in ioctl structs. As opposed to failing
the ioctl with mysterious EINVALs.
Also updated the following structs to NOT implement HasStatus interface:
- IoctlRegisterFD
- RMAPIVersion
- IoctlSysParams
These don't have a Status field so it is misleading for them to implement
HasStatus. Created frontendIoctlSimpleNoStatus() and
frontendIoctlInvokeNoStatus() for such structs to use.
PiperOrigin-RevId: 738959856
The following command does not report any changes in the structs we proxy:
```
make run TARGETS=//tools/nvidia_driver_differ:run_differ \
ARGS="--base 570.86.15 --next 570.124.06"
```
PiperOrigin-RevId: 738093448
TURING_A was added in e6e1ecbdcc ("Add support for graphics in nvproxy.").
{GPU_ARCH}_A class is used for graphics workloads. Add the missing classes for
other GPU architectures we support.
PiperOrigin-RevId: 726620575
nvproxy additionally branches at the following points which are not covered by
the ABI struct:
1. Frontend ioctl NV_ESC_RM_ALLOC_MEMORY on
nv_ioctl_nvos02_parameters_with_fd::params::hClass.
2. Frontend ioctl NV_ESC_RM_VID_HEAP_CONTROL on NVOS32_PARAMETERS::function.
In case nvproxy doesn't implement one of the values, it should print a warning
with the same prefix of "handler is undefined" which is used for other branch
points. This will make it easier to grep for missing nvproxy functionality.
Also update documentation for nvproxy debugging. Earlier, nvproxy logged
"nvproxy: unknown ..." for such situations. That changed with 6953ca0ca3
("Add NVIDIA driver capability segmentation support to nvproxy."), which moved
to using "nvproxy: handler is undefined ...".
PiperOrigin-RevId: 726565029
Also run the validate_checksum command on presubmit to avoid such issues.
Fixes 888f66d0a1 ("nvproxy: Add support for 535.230.02 driver.")
PiperOrigin-RevId: 720687756
Before this change, there were 2 places in which the driver struct names were
defined for nvproxy structs:
1. As struct field tags. The first field of structs had a tag `nvproxy:*`. This
was kind of awkward. Such metadata is usually a struct comment.
2. In version.go while registering the struct with a name. Not all structs are
defined in nvproxy (for example simple structs). In such cases, the driver
struct name is directly assigned while registering struct info.
This change gets rid of (1). Most of the struct tags were `nvproxy:"same"`. Now
driverStructs() always infers the driver struct name using the nvproxy struct
name itself. The few cases where the nvproxy tag was needed, because driver
struct name was lower cased, were handled by defining driverStructWithName()
which allows specifying a different name. Now all driver struct names
definitions are in one place.
Along the way, also made the following fixes:
- For some reason, many structs defined in pkg/abi/nvgpu/frontend.go had
camel-cased naming, while all other structs in pkg/abi/nvgpu/ctrl.go and
pkg/abi/nvgpu/classes.go were named the same as their driver structs. The
convention in the abi/* packages is to follow the kernel source naming.
This is against Go sytle guide, but is more readable for gVisor purposes and
has been a long accepted convention. This also makes the task of removing (1)
easier. So renamed all such structs as per their driver names.
- A lot of code in pkg/sentry/devices/nvproxy/version.go was still referring to
driver struct info as "struct names", even though it was representing more
than just struct names. It also contains the reflect.Type of the struct which
is used to compare the nvproxy struct layout to the driver struct layout.
PiperOrigin-RevId: 710648105
Most ioctl contain a `Status` field (which in driver code is of type NvStatus)
which indicates if the ioctl command succeeded or not. Non NV_OK=0 values
indicate some kind of failure. In case of failure, the ioctl(2) syscall still
succeeds. So the failure is currently not visible in gVisor strace/debug logs.
This helps flag instances where the host invocation of ioctl(2) resulted in a
failure in the driver.
This also helps avoid the usage of frontendIoctlSimple() in some cases.
frontendIoctlSimple() heap allocates a byte buffer. It is better to copy into
the ioctl params on the stack when possible.
PiperOrigin-RevId: 707312482
This wraps `nvproxy`'s `ioctl` handlers with wrappers that are
driver-capability-aware, and initially populates the ABI tree
with all functions marked as being available for capabilities
`compute` and `utility`.
It is not yet possible for the user to specify which capability
they want to enable. This should not cause a regression for users
because the hardcoded effective capability set is the one that is
currently specified for all current handlers.
Updates #9452.
Updates #10856.
PiperOrigin-RevId: 697824737
Ayush RanjanandgVisor bot
Jamie LiuandgVisor bot
2022tgoel
Etienne PerotandgVisor bot