From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] hw/Makefile.objs question
Date: Fri, 22 Jun 2012 12:23:49 +1000 [thread overview]
Message-ID: <4FE3D735.4060909@ozlabs.ru> (raw)
In-Reply-To: <4FE329EE.4020701@suse.de>
On 22/06/12 00:04, 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.
>
>>> 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.
Aaaa. This is the case and this is what I did at the first place but I thought it was wrong. Ok.
> *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.
2 Alex: seems that now we should build qemu+vfio like below:
diff --git a/Makefile.target b/Makefile.target
index 9820ce5..54b0214 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -154,9 +154,6 @@ endif
endif
obj-$(CONFIG_IVSHMEM) += ivshmem.o
-# VFIO PCI device assignment
-obj-$(CONFIG_VFIO_PCI) += vfio_pci.o
-
# Hardware support
ifeq ($(TARGET_ARCH), sparc64)
obj-y += hw/sparc64/
diff --git a/configure b/configure
index a48d84b..14e25e0 100755
--- a/configure
+++ b/configure
@@ -3735,12 +3735,9 @@ case "$target_arch2" in
*)
echo "CONFIG_NO_XEN=y" >> $config_target_mak
esac
-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
+if test "$vfio_pci" = "yes" -a "$target_softmmu" = "yes" ; then
+ echo "CONFIG_VFIO_PCI=y" >> $config_target_mak
+fi
case "$target_arch2" in
i386|x86_64|ppcemb|ppc|ppc64|s390x)
# Make sure the target and host cpus are compatible
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index d43f1df..647cf34 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -9,5 +9,7 @@ obj-y += pc_sysfw.o
obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
obj-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o kvm/i8254.o
obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
+# VFIO PCI device assignment
+obj-$(CONFIG_VFIO_PCI) += vfio_pci.o
obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index f573a95..c46a049 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -25,4 +25,7 @@ obj-$(CONFIG_FDT) += ../device_tree.o
# Xilinx PPC peripherals
obj-y += xilinx_ethlite.o
+# VFIO PCI device assignment
+obj-$(CONFIG_VFIO_PCI) += vfio_pci.o
+
obj-y := $(addprefix ../,$(obj-y))
> 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.
thanks!
--
Alexey
next prev parent reply other threads:[~2012-06-22 2:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-21 3:22 [Qemu-devel] hw/Makefile.objs question Alexey Kardashevskiy
2012-06-21 10:36 ` Andreas Färber
2012-06-21 11:21 ` Alexey Kardashevskiy
2012-06-21 12:19 ` Andreas Färber
2012-06-21 13:10 ` Alexey Kardashevskiy
2012-06-21 13:23 ` Anthony Liguori
2012-06-21 14:04 ` Andreas Färber
2012-06-21 15:52 ` Alex Williamson
2012-06-22 2:23 ` Alexey Kardashevskiy [this message]
2012-07-02 10:36 ` Paolo Bonzini
2012-07-02 12:10 ` Andreas Färber
2012-07-02 12:10 ` Alexey Kardashevskiy
2012-07-02 12:11 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE3D735.4060909@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).