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
From man TIOCPKT:
"""
In packet mode, each subsequent read(2) will return a packet that either
contains a single nonzero control byte, or has a single byte containing zero
('\0') followed by data written on the slave side of the pseudoterminal."
"""
This CL implements only the data portion of packet mode, not the control bytes,
but that seems to be enough to get xfce4-terminal to work.
PiperOrigin-RevId: 737175092
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
This set of changes adds:
- support for `xt_multiport_{,v1}` matchers for matching for
a range of ports and their inverse, i.e.,:
```
-m multiport [!] --[s|d]ports (PORT,...|PORT:PORT,...)
```
- support for `IP{,6}T_SO_GET_REVISION_MATCH` socket options,
which allows `iptables` to query for the highest supported
revision for a given matcher
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
When using overlayfs with tmpfs as the upper layer (common case), depending on
the application, a lot of whiteouts can be created. This leads to a lot of
memory allocation because new dentry and inode structs need to be allocated for
each whiteout. With this change, we at least avoid the inode allocations.
This is analogous with what Linux does. See fs/overlayfs/ovl_entry.h:ovl_fs's
field `whiteout` with comment "Shared whiteout cache".
PiperOrigin-RevId: 704897805
Now we don't need to trigger a second fault to figure out whether it was write
or read access.
Fixes#11008
Co-developed-by: Jamie Liu <jamieliu@google.com>
PiperOrigin-RevId: 697677262
Lucas Manning
Ayush Ranjan
Nicolas Lacasse
Jamie Liu
clickyotomy
2022tgoel
Andrei Vagin
Jing Chen
Jing Chen