From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4PRp-0003pg-CT for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:41:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4PRl-0005sP-An for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:41:05 -0500 Received: from mga14.intel.com ([192.55.52.115]:38197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4PRk-0005ru-RQ for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:41:01 -0500 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> From: "Lan, Tianyu" Message-ID: <5660000E.8020008@intel.com> Date: Thu, 3 Dec 2015 16:40:46 +0800 MIME-Version: 1.0 In-Reply-To: <1449095107.15753.144.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed 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: Alex Williamson 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 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. > 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.