[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] hw/Makefile.objs question

From: Andreas Färber
Subject: Re: [Qemu-devel] hw/Makefile.objs question
Date: Thu, 21 Jun 2012 16:04:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

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.

>> 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.


>>>> 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.

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]