All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Iouri Tarassov <iourit@linux.microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>,
	kys@microsoft.com, haiyangz@microsoft.com,
	sthemmin@microsoft.com, wei.liu@kernel.org, iourit@microsoft.com,
	linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code
Date: Fri, 28 Aug 2020 08:15:04 +0200	[thread overview]
Message-ID: <20200828061504.GC56396@kroah.com> (raw)
In-Reply-To: <8bf27b82-bdd9-6486-fbc9-aa6f7a3312e0@linux.microsoft.com>

On Thu, Aug 27, 2020 at 04:45:55PM -0700, Iouri Tarassov wrote:
> 
> On 8/14/2020 5:57 AM, Greg KH wrote:
> > On Fri, Aug 14, 2020 at 08:38:53AM -0400, Sasha Levin wrote:
> > > 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;
> > > +
> 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.

As I mentioned before, you need to document that somewhere (like maybe
preventing your code from being built on big endian systems?)

> User mode applications see this as an opaque 32 bit value (D3DKMTHANDLE). I
> prefer not to use the u32 definition to avoid mistakes when another integer
> or a 64-bit handle is assigned to the handle or  the handle is assigned to a
> 64 or 32 bit integer variable. There are many handles in the driver model
> (shared NT handle, d3dkmthandle, etc). Using a specific type allows to avoid
> assigning one handle to another.

Specific types are great, that is fine.

> > > +struct ntstatus {
> > > +	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 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.
> D3DKMTHANDLE is a 32-bit unsigned value (bitfield), not an integer.

Ok, again, please document this, and as these fields are crossing the
kernel/user boundry, use the correct types (hint, 'int' is never that
type).

> > > +struct winluid {
> > > +	uint a;
> > > +	uint b;
> > 
> > And now uint?  Come on, be consistent please :)
> 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.

thank you.

greg k-h

  reply	other threads:[~2020-08-28  6:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14 12:38 [PATCH 0/4] drivers: hv: Microsoft Virtual GPU Driver Sasha Levin
2020-08-14 12:38 ` [PATCH 1/4] drivers: hv: dxgkrnl: core code Sasha Levin
2020-08-14 12:55   ` Greg KH
2020-08-27 23:29     ` Iouri Tarassov
2020-08-28  6:01       ` Greg KH
2020-08-14 12:57   ` Greg KH
2020-08-27 23:45     ` Iouri Tarassov
2020-08-28  6:15       ` Greg KH [this message]
2020-08-14 13:04   ` Greg KH
2020-08-28  0:05     ` Iouri Tarassov
2020-08-28  6:12       ` Greg KH
2020-09-03 18:55         ` Iouri Tarassov
2020-09-03 19:32           ` Greg KH
2020-08-14 13:18   ` Wei Liu
2020-08-26 20:20     ` Iouri Tarassov
2020-08-27  0:12     ` Iouri Tarassov
2020-08-27 19:09     ` Iouri Tarassov
2020-08-21 13:53   ` Pavel Machek
2020-08-28  0:25     ` Iouri Tarassov
2020-08-28  6:17       ` Greg KH
2020-08-28  6:18       ` Greg KH
2020-09-03 21:39         ` Iouri Tarassov
2020-09-04  5:18           ` Greg KH
2020-08-14 12:38 ` [PATCH 2/4] drivers: hv: dxgkrnl: hook up dxgkrnl Sasha Levin
2020-08-14 12:38 ` [PATCH 3/4] drivers: hv: vmbus: " Sasha Levin
2020-08-14 12:38 ` [PATCH 4/4] drivers: hv: dxgkrnl: create a MAINTAINERS entry Sasha Levin
2020-08-14 13:04   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200828061504.GC56396@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=haiyangz@microsoft.com \
    --cc=iourit@linux.microsoft.com \
    --cc=iourit@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=sthemmin@microsoft.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.