From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYJxA-0004Y3-S0 for qemu-devel@nongnu.org; Fri, 12 Aug 2016 17:25:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYJx5-0002CT-PV for qemu-devel@nongnu.org; Fri, 12 Aug 2016 17:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38228) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYJx5-0002CM-JV for qemu-devel@nongnu.org; Fri, 12 Aug 2016 17:25:15 -0400 Date: Fri, 12 Aug 2016 15:25:13 -0600 From: Alex Williamson Message-ID: <20160812152513.311eecb4@t450s.home> In-Reply-To: <8acef86b-0375-d42e-e60d-93a24296f64f@nvidia.com> References: <1470251034-1555-1-git-send-email-kwankhede@nvidia.com> <1470251034-1555-3-git-send-email-kwankhede@nvidia.com> <20160809130023.636c4333@t450s.home> <20160810170044.077a61a7@t450s.home> <0b141f7e-8368-d369-58a1-01d6c1492167@nvidia.com> <20160811102421.7e05510d@t450s.home> <533fdd98-ac55-9a29-215c-66c58e848689@nvidia.com> <20160811124340.3c086a9d@t450s.home> <8acef86b-0375-d42e-e60d-93a24296f64f@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 2/4] vfio: VFIO driver for mediated PCI device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirti Wankhede Cc: pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com, jike.song@intel.com, bjsdjshi@linux.vnet.ibm.com On Fri, 12 Aug 2016 23:27:01 +0530 Kirti Wankhede wrote: > On 8/12/2016 12:13 AM, Alex Williamson wrote: > > > > > TBH, I don't see how providing a default implementation of > > validate_map_request() is useful. How many mediated devices are going > > to want to identity map resources from the parent? Even if they do, it > > seems we can only support a single mediated device per parent device > > since each will map the same parent resource offset. Let's not even try > > to define a default. If we get a fault and the vendor driver hasn't > > provided a handler, send a SIGBUS. I expect we should also allow > > vendor drivers to fill the mapping at mmap() time rather than expecting > > this map on fault scheme. Maybe the mid-level driver should not even be > > interacting with mmap() and should let the vendor driver entirely > > determine the handling. > > > > Should we go ahead with pass through mmap() call to vendor driver and > let vendor driver decide what to do in mmap() call, either > remap_pfn_range in mmap() or do fault on access and handle the fault in > their driver. In that case we don't need to track mappings in mdev core. > Let vendor driver do that on their own, right? This sounds right to me, I don't think we want to impose either model on the vendor driver. The vendor driver owns the vfio device file descriptor and is responsible for managing it should they expose mmap support for regions on the file descriptor. They either need to insert mappings at the point where mmap() is called or setup fault handlers to insert them on demand. If we can provide helper functions so that each vendor driver doesn't need to re-invent either of those, that would be a bonus. Thanks, Alex