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
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 makes logging slightly more consistent and less verbose (don't need
`h.Val` to avoid extraneous braces in the output), and improves type safety for
class IDs.
PiperOrigin-RevId: 624316076
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
Nvproxy now supports 535.54.03 and 535.104.05 versions.
Tested on T4 GPU for these versions.
```
$ docker run --runtime=runsc --rm --gpus=all nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubi8
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done
```
PiperOrigin-RevId: 572312006
Tested on 1 V100 GPU:
```
$ docker run --runtime=runsc --rm --gpus all nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda11.7.1-ubi8
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done
```
PiperOrigin-RevId: 549837326
Ayush RanjanandgVisor bot
2022tgoel
Jamie LiuandgVisor bot
Nathan Wang
Anthony CuiandgVisor bot
Jonathon Belotti
Otto BittnerandMalte Poll
Jing ChenandgVisor bot