From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmZiG-000160-Iq for qemu-devel@nongnu.org; Wed, 21 Sep 2016 01:04:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmZiD-0005lR-Cs for qemu-devel@nongnu.org; Wed, 21 Sep 2016 01:04:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:11002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmZiD-0005l7-7v for qemu-devel@nongnu.org; Wed, 21 Sep 2016 01:04:49 -0400 Message-ID: <57E2146F.9070400@intel.com> Date: Wed, 21 Sep 2016 13:02:39 +0800 From: Jike Song MIME-Version: 1.0 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> <20160920225152.5f96b897@t450s.home> In-Reply-To: <20160920225152.5f96b897@t450s.home> Content-Type: text/plain; charset=UTF-8 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: Alex Williamson 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 09/21/2016 12:51 PM, Alex Williamson wrote: > 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, > I misunderstood that previously and I understand the whole idea now. Thanks for the kind explanation! :) -- Thanks, Jike