Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp799547pxa; Thu, 27 Aug 2020 16:31:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6XWwH5QYCrfsNILHKtQW6nrrh8BknDefolAdmUingft1/TN1RreLskeY+pv6dS3TOmKwP X-Received: by 2002:a17:906:f292:: with SMTP id gu18mr24545670ejb.24.1598571061033; Thu, 27 Aug 2020 16:31:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598571061; cv=none; d=google.com; s=arc-20160816; b=J6kxvhGOUfHyGw2zK2ncM8M0z9cFQPs7f6iKnQ8wcQ/X/dMvQG37467RfN2vUr2cHx tV33iIlOyPRnS7/MOY9Wowu1c8vyiFIceYxDsNBOzbB5Ewx6WPqgbqeSNq4nmkVRkeNT Pr3eBZ37an0cBmk96cExvPPiO2ImNG/EL/8adJjxKjZ27oLUdwc41Nomjy/QET/mm+6Y PfBxjO4PkfcamGegnqMbFJqE9BSrGUZA2G+IEnhM4e8nCs9W8yxOMikDJofAI+nkWoQe 7iwPdB5U68zHEyal1mGnWZvX4nlvhjd4lfma6rzA6hUeXTh92JJutBlOia6k1vSv5S4u FYZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature:dkim-filter; bh=wuKHk2etmpOkKZ+mX7e+4wCZgquz5pl8IyY73pe5ZGE=; b=Uh2adMqEfPDY+V5ziJLqSmocgWfZ8VVCmv7nMOMZ/IwnjjqV2HFtG/dFMULCPQ0ZQW Fx67buuJ0HVZobcw5ju6T+pyxpfxKOtYBTLTB6enRjzTO+s7n3Ee+PFPN75Kuk8M88I5 LDX+6Y161H2r3F2fz4hPtMaUQudITE7TgQ5eXDkrUQQRvP0Ywvav1FzP57JjjW048abs IX4wNwlhDlrc6IZaMYY46PSlHWv8yOZXmDRDKu4++e/6f3pZhtnTpp4/LhvnrGO4A9sk 7HgmQepgALK2mrau/RuhExgnYKCPVr6ZMs+f1xk+FozxdR9ibsa3SWjZHzRZM1Inm9Hx F5FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=mdsSv4Ok; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ov32si2448833ejb.218.2020.08.27.16.30.36; Thu, 27 Aug 2020 16:31:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=mdsSv4Ok; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727834AbgH0XaB (ORCPT + 99 others); Thu, 27 Aug 2020 19:30:01 -0400 Received: from linux.microsoft.com ([13.77.154.182]:47858 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726147AbgH0XaA (ORCPT ); Thu, 27 Aug 2020 19:30:00 -0400 Received: from [192.168.1.17] (50-47-107-221.evrt.wa.frontiernet.net [50.47.107.221]) by linux.microsoft.com (Postfix) with ESMTPSA id E933820B7178; Thu, 27 Aug 2020 16:29:59 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E933820B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1598571000; bh=wuKHk2etmpOkKZ+mX7e+4wCZgquz5pl8IyY73pe5ZGE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mdsSv4OkGJMTMEOR4egTE96ddEeTMglYTT1hGi4Mg8TENH/qtgadEXQL0r3OVgcQD 52TN+lI4fLsEvE8/gDF2BhNlrwpElC61jUMDzf2H9Y4Cxf2BW5W/Y49hGX5a0mV9Ws CKRpea0tNFI2a/iRndFW6ApzdMv4xJh4gtCcnAm0= Subject: Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code To: Greg KH , Sasha Levin Cc: 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 References: <20200814123856.3880009-1-sashal@kernel.org> <20200814123856.3880009-2-sashal@kernel.org> <20200814125528.GA56456@kroah.com> From: Iouri Tarassov Message-ID: <58011269-e910-b3e4-2a3c-552b08c90574@linux.microsoft.com> Date: Thu, 27 Aug 2020 16:29:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200814125528.GA56456@kroah.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/14/2020 5:55 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. > > > > Signed-off-by: Sasha Levin > > Better, but what is this mess: > > > +#define ISERROR(ret) (ret < 0) The VM bus messages return the NTSTATUS error code from the host. NTSTATUS is integer and the positive values indicate success. The success error code needs to be returned by IOCTLs to the DxCore applications. The ISERROR() macro is used in places where the NTSTATUS success code could be returned from a function. "if (ret)" cannot be used. I will add a comment to the macro in the next patch. > > ? > > > +#define EINTERNALERROR EINVAL This macro will be removed in the next patch > And that? > > > + > > +#define DXGKRNL_ASSERT(exp) > > +#define UNUSED(x) (void)(x) The UNUSED macro will be removed. The DXGKRNL_ASSERT() macro will be changed to generate a memory dump and BUG_ON when DXGDEBUG is enabled. It is used to catch internal errors in the debug code. There will be no bugcheck in the released driver. > > Ick, no, please. > > > +#undef pr_fmt > > In a .h file? > > > +#define pr_fmt(fmt) "dxgk:err: " fmt > > +#define pr_fmt1(fmt) "dxgk: " fmt > > +#define pr_fmt2(fmt) "dxgk: " fmt This will be fixed in the next patch set. > Why? > > > + > > +#define DXGKDEBUG 1 > > +/* #define USEPRINTK 1 */ > > + > > +#ifndef DXGKDEBUG > > +#define TRACE_DEBUG(...) > > +#define TRACE_DEFINE(...) > > +#define TRACE_FUNC_ENTER(...) > > +#define TRACE_FUNC_EXIT(...) > > No, please do not to custom "trace" printk messages, that is what ftrace > is for, no individual driver should ever need to do that. > > Just use the normal dev_*() calls for error messages and the like, do > not try to come up with a custom tracing framework for one tiny > individual driver. If every driver in kernel did that, we would have a > nightmare... I understand the concern. This will be fixed later when we learn and pick the final tracing technology for the driver. The current implementation allows the hardware vendors to quickly identify issues without learning about ftrace. They just need to enable the WSL debug console and mount debugfs. > thanks, > > greg k-h > Thank you for your time and good comments. Iouri