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 6AF71C55199 for ; Mon, 27 Apr 2020 14:19:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 477E1206BF for ; Mon, 27 Apr 2020 14:19:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="g8Uwg6Wf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727801AbgD0OTE (ORCPT ); Mon, 27 Apr 2020 10:19:04 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:33597 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727985AbgD0OTD (ORCPT ); Mon, 27 Apr 2020 10:19:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587997142; 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=g8Uwg6WfE9yUric8ZwxaMAVJ9ppcQvYRH10QVxKfYtsd7ANsWVByy1hSSVgfCvROO7wUcr xoZosvZ0qYcWiiJCog43KMw5vmeewF6baFy6id4UZkqauDKUEQ9oS4GJ9nsTLrwqBozvqr AlAXQ4LUdnpJCjc1OZ8WVeczFDH/unU= 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: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@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