From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctvH5-00069r-Bz for qemu-devel@nongnu.org; Fri, 31 Mar 2017 08:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctvH2-0004nu-9n for qemu-devel@nongnu.org; Fri, 31 Mar 2017 08:03:27 -0400 References: <20170330124707.28142-1-aik@ozlabs.ru> <20170330124707.28142-3-aik@ozlabs.ru> <82c140ad-da36-5c2a-3f10-567d3108b15a@redhat.com> From: Paolo Bonzini Message-ID: <306e1353-2a82-79e3-7001-5933efbf01f3@redhat.com> Date: Fri, 31 Mar 2017 14:03:20 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH qemu 2/5] spapr-iommu: Subclass TYPE_IOMMU_MEMORY_REGION List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, David Gibson , Alex Williamson On 31/03/2017 13:47, Alexey Kardashevskiy wrote: >>> =20 >>> +static void spapr_iommu_memory_region_class_init(ObjectClass *k, voi= d *data) >>> +{ >>> + sPAPRIOMMUMemoryRegionClass *smrc =3D SPAPR_IOMMU_MEMORY_REGION_= CLASS(k); >>> + >>> + smrc->get_fd =3D spapr_tce_get_fd; >>> +} >>> + >> You don't even need the virtual function. Rather, make spapr_tce_get_= fd >> public and give it a sPAPRTCETable argument. Then vfio_spapr_notify_k= vm >> can use SPAPR_IOMMU_MEMORY_REGION(iommumr). > Well, if I make spapr_tce_get_fd() public, vfio_spapr_notify_kvm() coul= d > just take MemoryRegion and cast it to sPAPRTCETable without all these > dances with MemoryRegion, IOMMUMemoryRegion, what do I miss here? I hav= e > made a big patch with IOMMUMemoryRegion though, post it? *I* was missing that the call was inside an "if (container->iommu_type =3D= =3D TCE)". So the hierarchy is good to have, but the virtual function can be removed= . Paolo