Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965630AbbLRCF4 (ORCPT ); Thu, 17 Dec 2015 21:05:56 -0500 Received: from mail-pf0-f182.google.com ([209.85.192.182]:36612 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965138AbbLRCFy (ORCPT ); Thu, 17 Dec 2015 21:05:54 -0500 Subject: Re: [RFC PATCH 0/3] VFIO: capability chains To: Alex Williamson References: <20151123202614.18252.41590.stgit@gimli.home> Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org From: Alexey Kardashevskiy Message-ID: <567369FD.4000100@ozlabs.ru> Date: Fri, 18 Dec 2015 13:05:49 +1100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151123202614.18252.41590.stgit@gimli.home> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2288 Lines: 55 On 11/24/2015 07:43 AM, Alex Williamson wrote: > Please see the commit log and comments in patch 1 for a general > explanation of the problems that this series tries to address. The > general problem is that we have several cases where we want to expose > variable sized information to the user, whether it's sparse mmaps for > a region, as implemented here, or DMA mapping ranges of an IOMMU, or > reserved MSI mapping ranges, etc. Extending data structures is hard; > extending them to report variable sized data is really hard. After > considering several options, I think the best approach is to copy how > PCI does capabilities. This allows the ioctl to only expose the > capabilities that are relevant for them, avoids data structures that > are too complicated to parse, and avoids creating a new ioctl each > time we think of something else that we'd like to report. This method > also doesn't preclude extensions to the fixed structure since the > offset of these capabilities is entirely dynamic. > > Comments welcome, I'll also follow-up to the QEMU and KVM lists with > an RFC making use of this for mmaps skipping over the MSI-X table. > Thanks, Out of curiosity - could this information be exposed to the userspace via /sys/bus/pci/devices/xxxx:xx:xx:x/vfio_xxxx? It seems not to change after vfio_pci driver is bound to a device. > Alex > > --- > > Alex Williamson (3): > vfio: Define capability chains > vfio: Define sparse mmap capability for regions > vfio/pci: Include sparse mmap capability for MSI-X table regions > > > drivers/vfio/pci/vfio_pci.c | 101 +++++++++++++++++++++++++++++++++++++++++++ > include/uapi/linux/vfio.h | 53 ++++++++++++++++++++++- > 2 files changed, 152 insertions(+), 2 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/