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
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
This is helpful for handling parameter types that have one field for frontend
FD that needs to be translated (and are simple apart from that). Avoids
repetitive code.
Rename HasRMCtrlFD->HasFrontendFD so it can have a broader meaning.
Implement generic handlers for frontend ioctl and control commands.
Updates #10413.
PiperOrigin-RevId: 633700330
This is necessary to prevent osDescMem pinned page leaks when the osDescMem is
freed indirectly, e.g. by closing the `/dev/nvidiactl` FD that owns the
containing client.
- Switch from passing separate sentryIoctlParams to temporarily modifying
ioctlParams in-place, in order to ensure that callers of *Invoke functions
always observe ioctlParams updated by driver copy-out (including e.g. updated
handles).
- Only pass NVOS64Parameters (rather than NVOS21Parameters) in NV_ESC_RM_ALLOC
calls to the driver; this should behave equivalently (new comment in
rmAllocInvoke()) and simplifies passing them to object registration callbacks
(objAddLocked).
PiperOrigin-RevId: 627630863
Note that NV0000_CTRL_SYSTEM_GET_P2P_CAPS_V2_PARAMS changed in 550.40.07, but
it was still "simple" and can be handled with `rmControlSimple`. So no special
versioning logic needed.
PiperOrigin-RevId: 622926672
Tested on T4 GPU using image gcr.io/gvisor-presubmit/gpu/stable-diffusion-xl.
After this, the remaining error is a TTY error:
```
Error: your terminal supports neither 24-bit nor 8-bit colors. Other coloring
options aren't available
```
PiperOrigin-RevId: 610931919
Ayush RanjanandgVisor bot
2022tgoel
Nathan Wang
Otto Bittner
Anthony CuiandgVisor bot
Matt Nappo
Jonathon Belotti
Jamie LiuandgVisor bot