From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: RFC: vfio API changes needed for powerpc (v2) Date: Thu, 4 Apr 2013 17:51:49 -0500 Message-ID: <1365115909.14772.20@snotra> References: <9F6FE96B71CF29479FF1CDC8046E15035A29AC@039-SN1MPN1-003.039d.mgd.msft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15035A29AC@039-SN1MPN1-003.039d.mgd.msft.net> (from B08248@freescale.com on Thu Apr 4 16:38:44 2013) Content-Disposition: inline Sender: kvm-owner@vger.kernel.org To: Yoder Stuart-B08248 Cc: Alex Williamson , Wood Scott-B07421 , "agraf@suse.de" , Bhushan Bharat-R65777 , Sethi Varun-B16395 , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "iommu@lists.linux-foundation.org" List-Id: iommu@lists.linux-foundation.org On 04/04/2013 04:38:44 PM, Yoder Stuart-B08248 wrote: > > > > /* > > > * VFIO_PAMU_MAP_MSI_BANK > > > * > > > * Maps the MSI bank at the specified index and iova. User space > must > > > * call this ioctl once for each MSI bank (count of banks is > returned by > > > * VFIO_IOMMU_GET_MSI_BANK_COUNT). > > > * Caller provides struct vfio_pamu_msi_bank_map with all fields > set. > > > * Operates on VFIO file descriptor (/dev/vfio/vfio). > > > * Return: 0 on success, -errno on failure > > > */ > > > > > > struct vfio_pamu_msi_bank_map { > > > __u32 argsz; > > > __u32 msi_bank_index; /* the index of the MSI bank */ > > > __u64 iova; /* the iova the bank is to be mapped > to */ > > > }; > > > > Again, flags. If we dynamically add or remove devices from a > container > > the bank count can change, right? If bank count goes from 2 to 3, > does > > userspace know assume the new bank is [2]? If bank count goes from > 3 to > > 2, which index was that? If removing a device removes an MSI bank > then > > vfio-pamu will automatically do the unmap, right? > > My assumption is that the bank count returned by > VFIO_IOMMU_GET_MSI_BANK_COUNT > is the max bank count for a platform. (number will mostly likely > always be > 3 or 4). So it won't change as devices are added or removed. It should be the actual number of banks used. This is required if we're going to have userspace do the iteration and specify the exact iovas to use -- and even if we aren't going to do that, it would be more restrictive on available iova-space than is necessary. Usually there will be only one bank in the group. Actually mapping all of the MSI banks, all the time, would completely negate the point of using the separate alias pages. -Scott From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNt1a-00049Y-TQ for qemu-devel@nongnu.org; Thu, 04 Apr 2013 18:53:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNt1U-0008KP-DM for qemu-devel@nongnu.org; Thu, 04 Apr 2013 18:52:54 -0400 Received: from tx2ehsobe002.messaging.microsoft.com ([65.55.88.12]:46197 helo=tx2outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNt1U-0008KI-7l for qemu-devel@nongnu.org; Thu, 04 Apr 2013 18:52:48 -0400 Date: Thu, 4 Apr 2013 17:51:49 -0500 From: Scott Wood In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E15035A29AC@039-SN1MPN1-003.039d.mgd.msft.net> (from B08248@freescale.com on Thu Apr 4 16:38:44 2013) Message-ID: <1365115909.14772.20@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yoder Stuart-B08248 Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "agraf@suse.de" , "iommu@lists.linux-foundation.org" , "qemu-devel@nongnu.org" , Alex Williamson , Bhushan Bharat-R65777 , Sethi Varun-B16395 On 04/04/2013 04:38:44 PM, Yoder Stuart-B08248 wrote: >=20 > > > /* > > > * VFIO_PAMU_MAP_MSI_BANK > > > * > > > * Maps the MSI bank at the specified index and iova. User space =20 > must > > > * call this ioctl once for each MSI bank (count of banks is =20 > returned by > > > * VFIO_IOMMU_GET_MSI_BANK_COUNT). > > > * Caller provides struct vfio_pamu_msi_bank_map with all fields =20 > set. > > > * Operates on VFIO file descriptor (/dev/vfio/vfio). > > > * Return: 0 on success, -errno on failure > > > */ > > > > > > struct vfio_pamu_msi_bank_map { > > > __u32 argsz; > > > __u32 msi_bank_index; /* the index of the MSI bank */ > > > __u64 iova; /* the iova the bank is to be mapped =20 > to */ > > > }; > > > > Again, flags. If we dynamically add or remove devices from a =20 > container > > the bank count can change, right? If bank count goes from 2 to 3, =20 > does > > userspace know assume the new bank is [2]? If bank count goes from =20 > 3 to > > 2, which index was that? If removing a device removes an MSI bank =20 > then > > vfio-pamu will automatically do the unmap, right? >=20 > My assumption is that the bank count returned by =20 > VFIO_IOMMU_GET_MSI_BANK_COUNT > is the max bank count for a platform. (number will mostly likely =20 > always be > 3 or 4). So it won't change as devices are added or removed. It should be the actual number of banks used. This is required if =20 we're going to have userspace do the iteration and specify the exact =20 iovas to use -- and even if we aren't going to do that, it would be =20 more restrictive on available iova-space than is necessary. Usually =20 there will be only one bank in the group. Actually mapping all of the MSI banks, all the time, would completely =20 negate the point of using the separate alias pages. -Scott=