From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Vmf-0003XI-0x for qemu-devel@nongnu.org; Thu, 03 Dec 2015 10:27:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4VmZ-0000SM-RL for qemu-devel@nongnu.org; Thu, 03 Dec 2015 10:27:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60640) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4VmZ-0000Ru-K6 for qemu-devel@nongnu.org; Thu, 03 Dec 2015 10:26:55 -0500 Message-ID: <1449156413.15753.153.camel@redhat.com> From: Alex Williamson Date: Thu, 03 Dec 2015 08:26:53 -0700 In-Reply-To: <5660000E.8020008@intel.com> References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> <1448372127-28115-3-git-send-email-tianyu.lan@intel.com> <1449095107.15753.144.camel@redhat.com> <5660000E.8020008@intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Lan, Tianyu" Cc: emil.s.tantilov@intel.com, kvm@vger.kernel.org, ard.biesheuvel@linaro.org, aik@ozlabs.ru, donald.c.skidmore@intel.com, mst@redhat.com, eddie.dong@intel.com, agraf@suse.de, quintela@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, cornelia.huck@de.ibm.com, nrupal.jani@intel.com, kraxel@redhat.com, anthony@codemonkey.ws, amit.shah@redhat.com, pbonzini@redhat.com, mark.d.rustad@intel.com, lcapitulino@redhat.com, gerlitz.or@gmail.com On Thu, 2015-12-03 at 16:40 +0800, Lan, Tianyu wrote: > On 12/3/2015 6:25 AM, Alex Williamson wrote: > > I didn't seen a matching kernel patch series for this, but why is the > > kernel more capable of doing this than userspace is already? > The following link is the kernel patch. > http://marc.info/?l=kvm&m=144837328920989&w=2 > > > These seem > > like pointless ioctls, we're creating a purely virtual PCI capability, > > the kernel doesn't really need to participate in that. > > VFIO kernel driver has pci_config_map which indicates the PCI capability > position and length which helps to find free PCI config regs. Qemu side > doesn't have such info and can't get the exact table size of PCI > capability. If we want to add such support in the Qemu, needs duplicates > a lot of code of vfio_pci_configs.c in the Qemu. That's an internal implementation detail of the kernel, not motivation for creating a new userspace ABI. QEMU can recreate this data on its own. The kernel is in no more of an authoritative position to determine capability extents than userspace. > > Also, why are we > > restricting ourselves to standard capabilities? > > This version is to check whether it's on the right way and We can extend > this to pci extended capability later. > > > That's often a crowded > > space and we can't always know whether an area is free or not based only > > on it being covered by a capability. Some capabilities can also appear > > more than once, so there's context that isn't being passed to the kernel > > here. Thanks, > > The region outside of PCI capability are not passed to kernel or used by > Qemu for MSI/MSIX . It's possible to use these places for new > capability. One concerns is that guest driver may abuse them and quirk > of masking some special regs outside of capability maybe helpful. That's not correct, see kernel commit a7d1ea1c11b33bda2691f3294b4d735ed635535a. Gaps between capabilities are exposed with raw read-write access from the kernel and some drivers and devices depend on this. There's also no guarantee that there's a sufficiently sized gap in conventional space. Thanks, Alex