From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3AAAC04AB1 for ; Thu, 9 May 2019 13:54:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 80B2020675 for ; Thu, 9 May 2019 13:54:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557410090; bh=5aUZsPMDNITsiVWH42IYSX+Tk2YAwPnoE+eAF8ZDfGM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=x3+HC+ep9ShgzZDVucSINRimDLaeuOuabEIExeiwdzbHa2je3urXiFDk/4bZN+g40 IiM3OKNKlVz4zL1vDg2Pe91sHmxoX4xir8SKbve+8heCf3CB0VES30QuUpxKbGR3xs FS+HL486vLQLKYsa/WPtncG3NxwGTL1jQH7auv0o= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726687AbfEINyt (ORCPT ); Thu, 9 May 2019 09:54:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:28319 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726192AbfEINyt (ORCPT ); Thu, 9 May 2019 09:54:49 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 06:54:48 -0700 X-ExtLoop1: 1 Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga001.fm.intel.com with ESMTP; 09 May 2019 06:54:49 -0700 Date: Thu, 9 May 2019 07:49:17 -0600 From: Keith Busch To: Stefan Hajnoczi Cc: Maxim Levitsky , Christoph Hellwig , Fam Zheng , "Busch, Keith" , Sagi Grimberg , "kvm@vger.kernel.org" , Wolfram Sang , Greg Kroah-Hartman , "Liang, Cunming" , Nicolas Ferre , "linux-kernel@vger.kernel.org" , "linux-nvme@lists.infradead.org" , "David S . Miller" , Jens Axboe , Alex Williamson , Kirti Wankhede , Mauro Carvalho Chehab , Paolo Bonzini , "Liu, Changpeng" , "Paul E . McKenney" , Amnon Ilan , John Ferlan Subject: Re: [PATCH v2 00/10] RFC: NVME MDEV Message-ID: <20190509134917.GC8365@localhost.localdomain> References: <20190502114801.23116-1-mlevitsk@redhat.com> <20190503121838.GA21041@lst.de> <20190509091255.GB15331@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190509091255.GB15331@stefanha-x1.localdomain> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 09, 2019 at 02:12:55AM -0700, Stefan Hajnoczi wrote: > On Mon, May 06, 2019 at 12:04:06PM +0300, Maxim Levitsky wrote: > > On top of that, it is expected that newer hardware will support the PASID based > > device subdivision, which will allow us to _directly_ pass through the > > submission queues of the device and _force_ us to use the NVME protocol for the > > frontend. > > I don't understand the PASID argument. The data path will be 100% > passthrough and this driver won't be necessary. We still need a non-passthrough component to handle slow path, non-doorbell controller registers and admin queue. That doesn't necessarily need to be a kernel driver, though.