From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zeto9-0007nJ-3X for qemu-devel@nongnu.org; Wed, 23 Sep 2015 19:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zeto5-0000PO-Ok for qemu-devel@nongnu.org; Wed, 23 Sep 2015 19:50:41 -0400 Date: Thu, 24 Sep 2015 09:14:01 +1000 From: David Gibson Message-ID: <20150923231401.GB15944@voom.fritz.box> References: <1442495357-26547-1-git-send-email-david@gibson.dropbear.id.au> <1442495357-26547-2-git-send-email-david@gibson.dropbear.id.au> <56027F7D.7090705@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline In-Reply-To: <56027F7D.7090705@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 01/10] vfio: Remove unneeded union from VFIOContainer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: lvivier@redhat.com, aik@ozlabs.ru, gwshan@linux.vnet.ibm.com, qemu-devel@nongnu.org, alex.williamson@redhat.com, qemu-ppc@nongnu.org, pbonzini@redhat.com --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 12:31:25PM +0200, Thomas Huth wrote: > On 17/09/15 15:09, David Gibson wrote: > > Currently the VFIOContainer iommu_data field contains a union with > > different information for different host iommu types. However: > > * It only actually contains information for the x86-like "Type1" iom= mu > > * Because we have a common listener the Type1 fields are actually us= ed > > on all IOMMU types, including the SPAPR TCE type as well > > * There's no tag in the VFIOContainer to tell you which union member= is > > valid anyway. > >=20 > > In fact we now have a general structure for the listener which is unlik= ely > > to ever need per-iommu-type information, so this patch removes the unio= n. > >=20 > > In a similar way we can unify the setup of the vfio memory listener in > > vfio_connect_container() that is currently split across a switch on iom= mu > > type, but is effectively the same in both cases. > >=20 > > The iommu_data.release pointer was only needed as a cleanup function > > which would handle potentially different data in the union. With the > > union gone, it too can be removed. > >=20 > > Signed-off-by: David Gibson > > --- > > hw/vfio/common.c | 51 +++++++++++++++++------------------= -------- > > include/hw/vfio/vfio-common.h | 14 +++--------- > > 2 files changed, 23 insertions(+), 42 deletions(-) > ... > > diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-commo= n.h > > index 59a321d..aff18cd 100644 > > --- a/include/hw/vfio/vfio-common.h > > +++ b/include/hw/vfio/vfio-common.h > > @@ -64,21 +64,13 @@ typedef struct VFIOAddressSpace { > > =20 > > struct VFIOGroup; > > =20 > > -typedef struct VFIOType1 { > > - MemoryListener listener; > > - int error; > > - bool initialized; > > -} VFIOType1; > > - > > typedef struct VFIOContainer { > > VFIOAddressSpace *space; > > int fd; /* /dev/vfio/vfio, empowered by the attached groups */ > > struct { > > - /* enable abstraction to support various iommu backends */ > > - union { > > - VFIOType1 type1; > > - }; > > - void (*release)(struct VFIOContainer *); > > + MemoryListener listener; > > + int error; > > + bool initialized; > > } iommu_data; > > QLIST_HEAD(, VFIOGuestIOMMU) giommu_list; > > QLIST_HEAD(, VFIOGroup) group_list; > >=20 >=20 > I think I agree with Alexey here ... keeping the iommu_data struct > around those fields looks cumbersome. Is there a reason you did not > remove the struct completely? Uh.. it seemed like a good idea at the time? I'll remove it in the next spin. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --5I6of5zJg18YgZEa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWAzI5AAoJEGw4ysog2bOSRwwP+wQQKgBc1jQKco6o5nCpl/J8 1HAynFa8YUNyqpzS1xH3G6iW1BQdKkZ1MBdfb/ci8o+6XtoIiXn223XgKuKiLBq+ L1kLo0KpaIWnbHtP5xkIBIWX9YKv9b/iRspSlqSP3OzhLjOXMNeVPMvYoBnCXQQh R0iUk5ywjnNkvWbPtke4vJcqPGZLoxCK9nmUFQM4QsIRTPQxa9cg1D2BqwIzdJQl qtWSBlZS32qkb6PQCag9hrxz6OhQAvZWlnhyFgcJ+O56/9U/MzPFO+hOT+EVd2wJ ZKn5XR4H7OEuBVpM5XGF87I6ojuiNqbphtEhf7iZE/3PA52NGLXqBsqoCAmmqqg1 Roft0SVc6O8N+FUGrtUB5GBij/fY99xvp8mIMLx0TdERFftSHxykm0bjlT3ErNz0 7gyUbgVJK9gRsOJchSAsKHpEV/hwu2rXIdxfjVEO4Pryvrb1HwK3GB8vEUh3SXQM rRMDZRJm6B5g3aT9RfeHRVi5fV6+ADaN/ISw4DG7NfXZODLOaiGgWjssPPiyvX5E RrEXDsahUyGdelFBNdTs6ixivh4mkuwShMMHVE6cclRRRa2WIgd2938zoF8f/GZ+ waPH9xqlv09OwRYbHp5LTjeXkfB1MTwWUIcftVg6H5vFUJ5Aes9qQT26aBZ63z9L LPjNSfOxAtPvkjB/FbPO =uXaz -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa--