From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753362AbcKHSud (ORCPT ); Tue, 8 Nov 2016 13:50:33 -0500 Received: from hqemgate14.nvidia.com ([216.228.121.143]:6058 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454AbcKHSuH (ORCPT ); Tue, 8 Nov 2016 13:50:07 -0500 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 08 Nov 2016 10:50:05 -0800 Subject: Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops To: Alex Williamson References: <1478293856-8191-1-git-send-email-kwankhede@nvidia.com> <1478293856-8191-6-git-send-email-kwankhede@nvidia.com> <20161107123649.0f3d56e9@t450s.home> <20161108093952.58ced4d7@t450s.home> CC: , , , , , , , , X-Nvconfidentiality: public From: Kirti Wankhede Message-ID: <67cd108d-0792-d2d4-29d9-7560e472e7ce@nvidia.com> Date: Wed, 9 Nov 2016 00:17:53 +0530 MIME-Version: 1.0 In-Reply-To: <20161108093952.58ced4d7@t450s.home> X-Originating-IP: [10.24.70.42] X-ClientProxiedBy: BGMAIL103.nvidia.com (10.25.59.12) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/8/2016 10:09 PM, Alex Williamson wrote: > On Tue, 8 Nov 2016 19:25:35 +0530 > Kirti Wankhede wrote: > ... >>>> - >>>> + int (*pin_pages)(void *iommu_data, unsigned long *user_pfn, >>>> + int npage, int prot, >>>> + unsigned long *phys_pfn); >>>> + int (*unpin_pages)(void *iommu_data, >>> >>> Are we changing from long to int here simply because of the absurdity >>> in passing in more than a 2^31 entry array, that would already consume >>> more than 16GB itself? >>> >> >> These are on demand pin/unpin request, will that request go beyond 16GB >> limit? For Nvidia vGPU solution, pin request will not go beyond this limit. > > 16G is simply the size of the user_pfn or phys_pfn arrays at a maximal > int32_t npage value, the interface actually allows mapping up to 8TB > per call, but at that point we have 16GB of input, 16GB of output, and > 80GB of vfio_pfns created. So I don't really have a problem changing > form long to int given lack of scalability in the API in general, but > it does make me second guess the API itself. Thanks, > Changing to 'long', in future we might enhance this API without changing it signature. Thanks, Kirti