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=unavailable 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 C1F40C04A6B for ; Mon, 6 May 2019 16:49:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 906A620830 for ; Mon, 6 May 2019 16:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557161349; bh=A2ZU/b3h0mxlEc0X8cpHPYUJ57458AgZno287cDLTqc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=plO04Fr2mAXIQt9U9WW2z9ihGF1lLZm3jmgvIetU2ClGOiiOsujgjR637GsAoAfg6 ubA5G8MW0W27QHKF24v8VizW3MDuFmYsZOopRzCLKMjJJTMj7qdyH5gGGArgtcOG8j bv5Yh13TGLTEaNIw4HlimGupE4YLozut4hGBVjz0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726452AbfEFQtE (ORCPT ); Mon, 6 May 2019 12:49:04 -0400 Received: from mga14.intel.com ([192.55.52.115]:25683 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725883AbfEFQtD (ORCPT ); Mon, 6 May 2019 12:49:03 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2019 09:49:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,438,1549958400"; d="scan'208";a="230002448" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga001.jf.intel.com with ESMTP; 06 May 2019 09:49:01 -0700 Date: Mon, 6 May 2019 10:43:25 -0600 From: Keith Busch To: Christoph Hellwig Cc: Maxim Levitsky , 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: <20190506164325.GB2219@localhost.localdomain> References: <20190502114801.23116-1-mlevitsk@redhat.com> <20190503121838.GA21041@lst.de> <20190506125752.GA5288@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506125752.GA5288@lst.de> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, May 06, 2019 at 05:57:52AM -0700, Christoph Hellwig wrote: > > However, similar to the (1), when the driver will support the devices with > > hardware based passthrough, it will have to dedicate a bunch of queues to the > > guest, configure them with the appropriate PASID, and then let the guest useA > > these queues directly. > > We will not let you abuse the nvme queues for anything else. We had > that discussion with the mellanox offload and it not only unsafe but > also adds way to much crap to the core nvme code for corner cases. > > Or to put it into another way: unless your paravirt interface requires > zero specific changes to the core nvme code it is not acceptable at all. I agree we shouldn't specialize generic queues for this, but I think it is worth revisiting driver support for assignable hardware resources iff the specification defines it. Until then, you can always steer processes to different queues by assigning them to different CPUs.