From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShjgM-0008Bp-Br for qemu-devel@nongnu.org; Thu, 21 Jun 2012 11:52:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShjgH-0008P2-5r for qemu-devel@nongnu.org; Thu, 21 Jun 2012 11:52:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShjgG-0008Ol-UL for qemu-devel@nongnu.org; Thu, 21 Jun 2012 11:52:25 -0400 Message-ID: <1340293940.2839.20.camel@ul30vt> From: Alex Williamson Date: Thu, 21 Jun 2012 09:52:20 -0600 In-Reply-To: <4FE329EE.4020701@suse.de> References: <4FE29366.6050101@ozlabs.ru> <4FE2F912.1080904@suse.de> <4FE303A9.9010308@ozlabs.ru> <4FE31145.7040906@suse.de> <4FE31D53.5060700@ozlabs.ru> <4FE329EE.4020701@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] hw/Makefile.objs question List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?Q?F=E4rber?= Cc: Alexey Kardashevskiy , Paolo Bonzini , qemu-devel@nongnu.org, Anthony Liguori , Alexander Graf On Thu, 2012-06-21 at 16:04 +0200, Andreas F=C3=A4rber wrote: > Am 21.06.2012 15:10, schrieb Alexey Kardashevskiy: > > On 21/06/12 22:19, Andreas F=C3=A4rber wrote: > >> Am 21.06.2012 13:21, schrieb Alexey Kardashevskiy: > >>> On 21/06/12 20:36, Andreas F=C3=A4rber wrote: > >>>> Am 21.06.2012 05:22, schrieb Alexey Kardashevskiy: > >>>>> I am trying to compile the very last qemu with vfio_pci enabled. = VFIO_PCI is added as below: > >>>>> > >>>>> ./configure: > >>>>> > >>>>> case "$target_arch2" in > >>>>> i386|x86_64|ppc64) > >>>>> if test "$vfio_pci" =3D "yes" -a "$target_softmmu" =3D "yes"= ; then > >>>>> echo "CONFIG_VFIO_PCI=3Dy" >> $config_target_mak > >>>>> fi > >>>>> esac > >>>>> > >>>>> > >>>>> ./Makefile.target: > >>>>> > >>>>> # VFIO PCI device assignment > >>>>> obj-$(CONFIG_VFIO_PCI) +=3D vfio_pci.o > >>>>> > >>>>> > >>>>> And it worked before. However it does not anymore as it seems tha= t everything in hw/ (and vfio_pci.c > >>>>> as well as is in hw/ and it is a device) can be only compiled via= hw/Makefile.objs and > >>>>> hw/ppc/Makefile.objs (my platform is POWER), it is ignored if to = keep it as is. > >>>>> > >>>>> So I have to move "obj-$(CONFIG_VFIO_PCI) +=3D vfio_pci.o" to hw/= Makefile.objs (and change obj- to > >>>>> hw-obj-) but the hw/Makefile.objs does not include (directly or i= ndirectly) generated > >>>>> ppc64-softmmu/config-target.mak with CONFIG_VFIO_PCI=3Dy. > >>>>> > >>>>> What is the correct solution? > >>>> > >>>> If the file compiles the same for all three, put CONFIG_VFIO_PCI=3D= y into > >>>> default-configs/{i386,x86_64,ppc64}-softmmu.mak and do > >>>> hw-obj-$(CONFIG_VFIO_PCI) +=3D in hw/Makefile.objs. > >>> > >>> > >>> It only compiles with ./configure --enable-vfio-pci which may or ma= y not set CONFIG_VFIO_PCI to "y". > >>> Your proposal makes it always "y" (for selected platforms). > >> > >> Apply some creativity, there's surely examples around. The question = is > >> whether the contents of vfio_pci.o changes or not. > >=20 > > Applied already and gave up, this is why I am writing here :) > > What would be a good example of a device which is enabled by configur= e script? >=20 > You're missing my point: We need to know *where* the .o file needs to > go, then we can point you to appropriate examples. Making things depend > on configure options should be trivial from there. >=20 > My understanding is that VFIO depends only on Linux/KVM support so I > don't understand why you'd be excluding VFIO for ppc. s390 has no PCI > AFAIU so that'd be okay. FWIW, VFIO really only depends on Linux + PCI, but we probably want to set defaults so that it doesn't get build on platforms where we know it won't work (no INTx EOI lookup/notifiers). Thanks, Alex > >> If not, then you only > >> need to build it once in libhwX/, depending on $config_target_mak, a= nd > >> link to the appropriate targets. If it accesses CPU internals then i= t > >> must be built per target. > >=20 > > $config_target_mak points to ppc64-softmmu/config-target.mak, not in = the root folder. > > When executed in libhw64, it is not visible to makefile. >=20 > Correct. You keep mixing up both approaches I named... >=20 > *If* the file is built per target (hw/ppc64/Makefile.objs), then you ca= n > use *-softmmu/config-target.mak and just need to use a different > Makefile than before. >=20 > *If* the file is built per libhw (hw/Makefile.objs), then you need one > option whether to compile it and another for whether to link it into a > particular target. >=20 > You still haven't answered the question of which of these two cases > applies here, so I cannot say more than I already have. Anthony's 3) > elaborates on my briefly mentioned ifeq. >=20 > Andreas >=20 > >>>> Otherwise, add to hw/{i386,ppc}/Makefile.objs - or with Anthony's > >>>> proposal from yesterday hw/Makefile.objs becomes possible, too. > >>> > >>> Again, it will be unconditional "y". > >> > >> No, in this case the condition would be set from configure as before= , it > >> only moves from Makefile.target to the appropriate Makefile.objs. > >> Note that to limit it to ppc64 (as opposed to ppc) some additional i= feq > >> check would be needed, as before. >=20