On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:The definition is the same as on the Windows side. The driver communicates with a Windows host, so I do not expect any issues with endiannes. Windows currently runs only on the little endian platforms.
> Add support for a Hyper-V based vGPU implementation that exposes the
> DirectX API to Linux userspace.
Api questions:
> +struct d3dkmthandle {
> + union {
> + struct {
> + u32 instance : 6;
> + u32 index : 24;
> + u32 unique : 2;
What is the endian of this?
> + };
> + u32 v;
> + };
> +};
> +
> +extern const struct d3dkmthandle zerohandle;
> +
> +struct ntstatus {"struct ntstatus" follows the definition for NTSTATUS on the Windows side. NTSTATUS is an integer where the negative values indicate errors. It is success otherwise. NTSTATUS is returned by the VM bus messages from host. IOCTLs from the driver return Linux negative error code or NTSTATUS positive success codes. DxCore applications expect certain positive success codes. DxCore is a shared library, which translates the D3DKMT* Windows interface to Linux ioctls. Applications link with DxCore to use a paravirtualized GPU.
> + union {
> + struct {
> + int code : 16;
> + int facility : 13;
> + int customer : 1;
> + int severity : 2;
Same here.
Are these things that cross the user/kernel boundry?
And why int on one and u32 on the other?
> + };
> + int v;
> + };
> +};
> +
> +struct winluid {Sorry about this. This came from the Windows size where we use UINT a lot. All uints will be replaced by u32 in the next patch set.
> + uint a;
> + uint b;
And now uint? Come on, be consistent please :)
Thank you
thanks,
greg k-h