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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 C8540C11F66 for ; Tue, 13 Jul 2021 05:37:44 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 44CF060C3F for ; Tue, 13 Jul 2021 05:37:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44CF060C3F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:50546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m3B70-000695-TE for qemu-devel@archiver.kernel.org; Tue, 13 Jul 2021 01:37:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3B0V-0002r9-7y; Tue, 13 Jul 2021 01:30:59 -0400 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]:49750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m3B0S-0008HL-TO; Tue, 13 Jul 2021 01:30:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sB+NFj9NADKAxiEcRKRS7St86v6A8h4ntYhh2hdlodA=; b=LN1XKIoPELsBvXzKzzaBw4VzYF iGXLvwamc+iMaAunMrBmSmdhd2dRIXVTPAN/MkZ6y5Jbxh5aqZ1SLwj6/M/pwpid9QNOhrgk/Qp1N 3/LdjyhgIT8skCpgoyLVGs6D+rf5ZGeh3q3uSm+10AX2Ggz6YC0fZRI8IyXM7mOk4kBBgDrJuhHMP UeMD9oMHg5cJJp2Jo2DNgBjR2fnVbUo+zGi1aQFiZ/ezofsjVovKXnA91B8c6NSiAYTe9pYPQMqy7 9lSuMil0vUTRrO8bIGEZfI6YkPlxXIWxbcM3bKxfzQIP3pOJyTW8fxMIl2S/0htVDo0xrqdGMoYAQ 7DMbl95g==; Received: from hch by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3B00-000lln-Nl; Tue, 13 Jul 2021 05:30:30 +0000 Date: Tue, 13 Jul 2021 06:30:28 +0100 From: Christoph Hellwig To: Stefan Hajnoczi Subject: Re: [RFC PATCH 1/2] hw/nvme: add mi device Message-ID: References: <20210709135545.GA11148@test-zns> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Received-SPF: none client-ip=2001:8b0:10b:1236::1; envelope-from=BATV+5ed7718f52b0c846131f+6533+infradead.org+hch@casper.srs.infradead.org; helo=casper.infradead.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fam@euphon.net, kwolf@redhat.com, jg123.choi@samsung.com, qemu-block@nongnu.org, k.jensen@samsung.com, d.palani@samsung.com, qemu-devel@nongnu.org, linux-nvme@lists.infradead.org, mreitz@redhat.com, its@irrelevant.dk, u.kishore@samsung.com, Padmakar Kalghatgi , kbusch@kernel.org, javier.gonz@samsung.com, prakash.v@samsung.com, mohit.kap@samsung.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Jul 12, 2021 at 12:03:27PM +0100, Stefan Hajnoczi wrote: > Why did you decide to implement -device nvme-mi as a device on > TYPE_NVME_BUS? If the NVMe spec somehow requires this then I'm surprised > that there's no NVMe bus interface (callbacks). It seems like this could > just as easily be a property of an NVMe controller -device > nvme,mi=on|off or -device nvme-subsys,mi=on|off? I'm probably just not > familiar enough with MI and NVMe architecture... I'm too far away from qemu these days to understand what TYPE_NVME_BUS is. Bt NVMe-MI has tree possible transports: 1) out of band through smbus. This seems something that could be trivially modelled in qemu 2) out of band over MCTP / PCIe VDM. 3) in band using NVMe admin commands that pass through MI commands