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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 8523DCA9EC3 for ; Tue, 29 Oct 2019 16:07:17 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (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 56E7321721 for ; Tue, 29 Oct 2019 16:07:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56E7321721 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 1C5ACC91; Tue, 29 Oct 2019 16:07:17 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 89407C3F for ; Tue, 29 Oct 2019 16:07:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 218B087C for ; Tue, 29 Oct 2019 16:07:15 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2019 09:07:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,244,1569308400"; d="scan'208";a="283283458" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga001.jf.intel.com with ESMTP; 29 Oct 2019 09:07:14 -0700 Date: Tue, 29 Oct 2019 09:11:39 -0700 From: Jacob Pan To: "Tian, Kevin" Subject: Re: [PATCH v7 09/11] iommu/vt-d: Add bind guest PASID support Message-ID: <20191029091139.7ddc155f@jacob-builder> In-Reply-To: References: <1571946904-86776-1-git-send-email-jacob.jun.pan@linux.intel.com> <1571946904-86776-10-git-send-email-jacob.jun.pan@linux.intel.com> <20191025103337.1e51c0c9@jacob-builder> <20191028090231.4777c6a9@jacob-builder> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: "Raj, Ashok" , David Woodhouse , "iommu@lists.linux-foundation.org" , LKML , Alex Williamson , Jean-Philippe Brucker , Jonathan Cameron X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org On Tue, 29 Oct 2019 07:57:21 +0000 "Tian, Kevin" wrote: > > From: Jacob Pan [mailto:jacob.jun.pan@linux.intel.com] > > Sent: Tuesday, October 29, 2019 12:03 AM > > > > On Mon, 28 Oct 2019 06:03:36 +0000 > > "Tian, Kevin" wrote: > > > > > > > > + .sva_bind_gpasid = intel_svm_bind_gpasid, > > > > > > + .sva_unbind_gpasid = > > > > > > intel_svm_unbind_gpasid, +#endif > > > > > > > > > > again, pure PASID management logic should be separated from > > > > > SVM. > > > > I am not following, these two functions are SVM functionality, > > > > not pure PASID management which is already separated in > > > > ioasid.c > > > > > > I should say pure "scalable mode" logic. Above callbacks are not > > > related to host SVM per se. They are serving gpasid requests from > > > guest side, thus part of generic scalable mode capability. > > Got your point, but we are sharing data structures with host SVM, > > it is very difficult and inefficient to separate the two. > > I don't think difficulty is the reason against such direction. We > need do things right. :-) I'm fine with putting it in a TODO list, > but at least need the right information in the 1st place to tell that > current way is just a short-term approach, and we should revisit > later. I guess the fundamental question is: Should the scalable mode logic, i.e. guest SVA at PASID granu device, be perceived as part of the overall SVA functionality? My view is yes, we shall share SVA and gSVA whenever we can. The longer term, which I am working on right now, is to converge intel_svm_bind_mm to the generic iommu_sva_bind_device() and use common data structures as well. It is conceivable that these common structures span across hardware architectures, also guest vs host SVA usages. i.e. iommu_ops have iommu_sva_bind_gpasid() for SM/gSVA iommu_sva_bind_device() for native SVA Or I am missing your point completely? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu