On Thu, 2012-06-21 at 16:04 +0200, Andreas Färber wrote:
> Am 21.06.2012 15:10, schrieb Alexey Kardashevskiy:
> > On 21/06/12 22:19, Andreas Färber wrote:
> >> Am 21.06.2012 13:21, schrieb Alexey Kardashevskiy:
> >>> On 21/06/12 20:36, Andreas Färber 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" = "yes" -a "$target_softmmu" = "yes" ; then
> >>>>> echo "CONFIG_VFIO_PCI=y" >> $config_target_mak
> >>>>> fi
> >>>>> esac
> >>>>>
> >>>>>
> >>>>> ./Makefile.target:
> >>>>>
> >>>>> # VFIO PCI device assignment
> >>>>> obj-$(CONFIG_VFIO_PCI) += vfio_pci.o
> >>>>>
> >>>>>
> >>>>> And it worked before. However it does not anymore as it seems that
> >>>>> 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) += vfio_pci.o" to
> >>>>> hw/Makefile.objs (and change obj- to
> >>>>> hw-obj-) but the hw/Makefile.objs does not include (directly or
> >>>>> indirectly) generated
> >>>>> ppc64-softmmu/config-target.mak with CONFIG_VFIO_PCI=y.
> >>>>>
> >>>>> What is the correct solution?
> >>>>
> >>>> If the file compiles the same for all three, put CONFIG_VFIO_PCI=y into
> >>>> default-configs/{i386,x86_64,ppc64}-softmmu.mak and do
> >>>> hw-obj-$(CONFIG_VFIO_PCI) += in hw/Makefile.objs.
> >>>
> >>>
> >>> It only compiles with ./configure --enable-vfio-pci which may or may 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.
> >
> > 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 configure
> > script?
>
> 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.
>
> 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, and
> >> link to the appropriate targets. If it accesses CPU internals then it
> >> must be built per target.
> >
> > $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.
>
> Correct. You keep mixing up both approaches I named...
>
> *If* the file is built per target (hw/ppc64/Makefile.objs), then you can
> use *-softmmu/config-target.mak and just need to use a different
> Makefile than before.
>
> *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.
>
> 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.
>
> Andreas
>
> >>>> 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 ifeq
> >> check would be needed, as before.
>
