From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmZVm-0003My-Nq for qemu-devel@nongnu.org; Wed, 21 Sep 2016 00:51:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmZVi-00025J-I2 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 00:51:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmZVi-00025F-86 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 00:51:54 -0400 Date: Tue, 20 Sep 2016 22:51:52 -0600 From: Alex Williamson Message-ID: <20160920225152.5f96b897@t450s.home> In-Reply-To: <57E1FC35.7010802@intel.com> References: <1472097235-6332-1-git-send-email-kwankhede@nvidia.com> <1472097235-6332-3-git-send-email-kwankhede@nvidia.com> <20160825172226.2cd06d71@oc7835276234> <72e3baa7-70d1-c5dd-6cd7-3874e7ea4c01@nvidia.com> <1a5e06cb-35bf-e7e3-0c0c-1ebf0fa95dcd@nvidia.com> <20160919123612.61b81ece@t450s.home> <8f4ace28-08bb-5afa-e6af-61395aa44ae1@nvidia.com> <20160919140332.26d6900b@t450s.home> <57E0A407.4020305@intel.com> <20160920102415.33ed7774@t450s.home> <57E1FC35.7010802@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 2/4] vfio: VFIO driver for mediated devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jike Song Cc: Kirti Wankhede , kraxel@redhat.com, Dong Jia , kevin.tian@intel.com, cjia@nvidia.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com On Wed, 21 Sep 2016 11:19:17 +0800 Jike Song wrote: > On 09/21/2016 12:24 AM, Alex Williamson wrote: > > On Tue, 20 Sep 2016 10:50:47 +0800 > > Jike Song wrote: > > /* trim the quotations */ > > >> Even performing a lightweight sanity check, would require vfio-mdev > >> to be able to decode the ppos into a particular region, that means > >> information of all regions should be stored in the framework. I guess > >> it is not your preferred way :) > > > > There's certainly a trade-off there, we don't support dynamic regions, > > the user expects them to be stable and the mdev-core code can expect > > that also. It might simplify the vendor drivers slightly if the core > > could perform such a basic sanity test, but the cost to do so would be > > that the core needs to have an understanding of the region layout of > > the device. > > I agree with why the requirement is, but I am suspicious that, > if we assume the regions are stable, try to encode/decode that within > the mdev-core framework - instead of vendor drivers - that is because > we want mdev to be API compatible with vfio-pci? > > Being API compatible with vfio-pci is (IMHO) the most beautiful thing > in current mdev design, but is it necessary to make it mandatory? > How about letting the underlining vendor drivers to decide whether > it is API compatible with vfio-pci, or will have a different set of > userspace API? Are you assuming that I'm suggesting using VFIO_PCI_OFFSET_TO_INDEX in the mdev core? We've been through that, I've rejected it, that's not at all what I'm describing. The vfio bus driver defines the region layout, but once defined it is fixed for a given device instance. A user does not need to call ioctl(VFIO_DEVICE_GET_REGION_INFO) prior to every region access to make sure the region offsets haven't changed dynamically. If it's fixed to the user than it's also fixed to the mdev core for a given device instance, so nothing prevents the core code from doing its own enumeration of the region offsets and sizes and caching them into data structures. That has nothing whatsoever to do with vfio-pci and makes no assumptions about the layout of regions within device fd. Thanks, Alex