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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 5E7F9C54FCB for ; Mon, 27 Apr 2020 14:19:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B03B206B9 for ; Mon, 27 Apr 2020 14:19:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ORimj9iS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727996AbgD0OTI (ORCPT ); Mon, 27 Apr 2020 10:19:08 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:20914 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727077AbgD0OTI (ORCPT ); Mon, 27 Apr 2020 10:19:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587997146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=//IIDXbV7XRjpK24m7Wh2m8pTq6hYTKHqfhZLqX4Iik=; b=ORimj9iSdLR5KWHjYmgwKOJ2hx5opNBmZ6YIEd3yPrAFd6ruVK/uFzzFS+rjDB+5Jo5724 OCOIXuZ0YydaQQQC+PlatkvGcJZAAfOSrb71gVpTyiPOdma+gBNngV73fixHCwWfooYZfZ Qodpp+7gtKUz9dU3EADt8ClE9t5yLTs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-358-Zad7BFGDMceHE1Cw8nJ5Ag-1; Mon, 27 Apr 2020 10:18:58 -0400 X-MC-Unique: Zad7BFGDMceHE1Cw8nJ5Ag-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 81BE8928E37; Mon, 27 Apr 2020 14:18:46 +0000 (UTC) Received: from x1.home (ovpn-112-162.phx2.redhat.com [10.3.112.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id E06E31002388; Mon, 27 Apr 2020 14:18:41 +0000 (UTC) Date: Mon, 27 Apr 2020 08:18:41 -0600 From: Alex Williamson To: Jason Gunthorpe Cc: "Tian, Kevin" , "Raj, Ashok" , "Jiang, Dave" , "vkoul@kernel.org" , "megha.dey@linux.intel.com" , "maz@kernel.org" , "bhelgaas@google.com" , "rafael@kernel.org" , "gregkh@linuxfoundation.org" , "tglx@linutronix.de" , "hpa@zytor.com" , "Pan, Jacob jun" , "Liu, Yi L" , "Lu, Baolu" , "Kumar, Sanjay K" , "Luck, Tony" , "Lin, Jing" , "Williams, Dan J" , "kwankhede@nvidia.com" , "eric.auger@redhat.com" , "parav@mellanox.com" , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "linux-pci@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH RFC 00/15] Add VFIO mediated device support and IMS support for the idxd driver. Message-ID: <20200427081841.18c4a994@x1.home> In-Reply-To: <20200427132218.GG13640@mellanox.com> References: <20200423191217.GD13640@mellanox.com> <20200424124444.GJ13640@mellanox.com> <20200424181203.GU13640@mellanox.com> <20200426191357.GB13640@mellanox.com> <20200426214355.29e19d33@x1.home> <20200427115818.GE13640@mellanox.com> <20200427071939.06aa300e@x1.home> <20200427132218.GG13640@mellanox.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Mon, 27 Apr 2020 10:22:18 -0300 Jason Gunthorpe wrote: > On Mon, Apr 27, 2020 at 07:19:39AM -0600, Alex Williamson wrote: > > > > It is not trivial masking. It is a 2000 line patch doing comprehensive > > > emulation. > > > > Not sure what you're referring to, I see about 30 lines of code in > > vdcm_vidxd_cfg_write() that specifically handle writes to the 4 BARs in > > config space and maybe a couple hundred lines of code in total handling > > config space emulation. Thanks, > > Look around vidxd_do_command() > > If I understand this flow properly.. I've only glanced at it, but that's called in response to a write to MMIO space on the device, so it's implementing a device specific register. Are you asking that PCI config space be done in userspace or any sort of device emulation? The assumption with mdev is that we need emulation in the host kernel because we need a trusted entity to mediate device access and interact with privileged portion of the device control. Thanks, Alex