From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5jzC-0007P5-N6 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 20:16:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5jz9-0003H4-DJ for qemu-devel@nongnu.org; Thu, 18 Jun 2015 20:16:46 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:36415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5jz9-0003Gf-6s for qemu-devel@nongnu.org; Thu, 18 Jun 2015 20:16:43 -0400 Received: by paceq1 with SMTP id eq1so47477906pac.3 for ; Thu, 18 Jun 2015 17:16:42 -0700 (PDT) References: <1434627456-13745-1-git-send-email-aik@ozlabs.ru> <1434627456-13745-3-git-send-email-aik@ozlabs.ru> <1434661828.3700.111.camel@redhat.com> From: Alexey Kardashevskiy Message-ID: <55835F62.8090802@ozlabs.ru> Date: Fri, 19 Jun 2015 10:16:34 +1000 MIME-Version: 1.0 In-Reply-To: <1434661828.3700.111.camel@redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu v8 02/14] vfio: spapr: Move SPAPR-related code to a separate file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: David Gibson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Gavin Shan , Alexander Graf On 06/19/2015 07:10 AM, Alex Williamson wrote: > On Thu, 2015-06-18 at 21:37 +1000, Alexey Kardashevskiy wrote: >> This moves SPAPR bits to a separate file to avoid pollution of x86 code. >> >> This enables spapr-vfio on CONFIG_SOFTMMU (not CONFIG_PSERIES) as >> the config options are only visible in makefiles and not in the source code >> so there is no an obvious way of implementing stubs if hw/vfio/spapr.c is >> not compiled. >> >> This is a mechanical patch. > > > Why does spapr code always need to be pulled out of common code and > private interfaces exposed to be called in ad-hock ways? Doesn't that > say something about a lack of design in the implementation? Why not > also pull out type1 support and perhaps create an interface between vfio > common code and vfio iommu code? But how exactly? A container_ops struct with 2 callbacks: init_listener()/ioctl(), per IOMMU type? vfio_container_ioctl() does not do anything spapr-specific (its existance is spapr-specific though). And I will still have to expose vfio_dma_map()/vfio_dma_unmap() to these new spapr.c and type1.c (move these map/unmap helpers to common_api.c?). And then I'll be told to make a container an QOM object, with class and state. btw why are not they all QOM-ed already? :) And I also need to expose ioctl(vfio_kvm_device_fd,...) but it does not belong to container. Most likely other IOMMUs will look pretty much the same as TYPE1, ours is just really weird (is there any other arch exposing IOMMU ot the guest?). -- Alexey