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
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
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 adds specific handling for NV0000_CTRL_GPU_GET_ID_INFO_PARAMS and
NV0000_CTRL_SYSTEM_GET_P2P_CAPS_PARAMS since they contain pointer fields.
This also fixes the layout of NV0000_CTRL_OS_UNIX_GET_EXPORT_OBJECT_INFO_PARAMS
and NV_CONFIDENTIAL_COMPUTE_ALLOC_PARAMS, and the typing of fields for
NV0000_CTRL_OS_UNIX_EXPORT_OBJECT and UVM_MAP_EXTERNAL_ALLOCATION_PARAMS.
PiperOrigin-RevId: 659630154
This is a necessary addition to enable our Nvidia driver differ tool, and
in general to make it easier to keep nvproxy up to date with driver changes.
The current maps have been partially validated by the test in cl/655637570.
PiperOrigin-RevId: 657705274
Ayush RanjanandgVisor bot
Jamie LiuandgVisor bot
2022tgoel
Nathan Wang
Otto Bittner
Anthony CuiandgVisor bot
Matt Nappo
Jonathon Belotti