From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kirti Wankhede Subject: Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops Date: Wed, 9 Nov 2016 00:17:53 +0530 Message-ID: <67cd108d-0792-d2d4-29d9-7560e472e7ce@nvidia.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Cc: , , , , , , , , To: Alex Williamson Return-path: In-Reply-To: <20161108093952.58ced4d7@t450s.home> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.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