There does not seem to be any target specific code in these files, so
we can put them into "common-obj" instead of "obj" to compile them only
once for all targets.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Makefile.objs   | 1 +
 Makefile.target | 3 +--
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 0575802..a949502 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -40,6 +40,7 @@ io-obj-y = io/
 
 ifeq ($(CONFIG_SOFTMMU),y)
 common-obj-y = blockdev.o blockdev-nbd.o block/
+common-obj-y += balloon.o numa.o bootdevice.o
 common-obj-y += iothread.o
 common-obj-y += net/
 common-obj-y += qdev-monitor.o device-hotplug.o
diff --git a/Makefile.target b/Makefile.target
index ce8dfe4..da37258 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -139,8 +139,7 @@ endif #CONFIG_BSD_USER
 #########################################################
 # System emulator target
 ifdef CONFIG_SOFTMMU
-obj-y += arch_init.o cpus.o monitor.o gdbstub.o balloon.o ioport.o numa.o
-obj-y += qtest.o bootdevice.o
+obj-y += arch_init.o cpus.o monitor.o gdbstub.o ioport.o qtest.o
 obj-y += hw/
 obj-$(CONFIG_KVM) += kvm-all.o
 obj-y += memory.o cputlb.o
-- 
1.8.3.1

Thomas Huth <thuth@redhat.com> wrote:
> There does not seem to be any target specific code in these files, so
> we can put them into "common-obj" instead of "obj" to compile them only
> once for all targets.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Again, nothing strange on that files that looks target specific.

On 08.06.2017 16:18, Thomas Huth wrote:
> There does not seem to be any target specific code in these files, so
> we can put them into "common-obj" instead of "obj" to compile them only
> once for all targets.

Self-NACK: balloon.c uses kvm_enabled() which in turn depends on
CONFIG_KVM ... and that flag is target-specific, so balloon.o can not be
moved to common-obj right now.

We should poison CONFIG_KVM for common code ... I'll have a look into
that...

 Thomas

On 14/06/2017 13:18, Thomas Huth wrote:
> On 08.06.2017 16:18, Thomas Huth wrote:
>> There does not seem to be any target specific code in these files, so
>> we can put them into "common-obj" instead of "obj" to compile them only
>> once for all targets.
> 
> Self-NACK: balloon.c uses kvm_enabled() which in turn depends on
> CONFIG_KVM ... and that flag is target-specific, so balloon.o can not be
> moved to common-obj right now.
> 
> We should poison CONFIG_KVM for common code ... I'll have a look into
> that...

No, your patch is okay.

#if defined CONFIG_KVM || !defined NEED_CPU_H
#define kvm_enabled()           (kvm_allowed)
...
#else
#define kvm_enabled()           (0)

In other words, kvm_enabled() forces itself to be 0 only in per-target
files.  This is done mostly to limit the number of required stubs:
target-independent APIs can be called from compile-once files and must
be stubbed; target-specific APIs can only be called from per-target
files, and their calls are culled by the compiler if !CONFIG_KVM.

Paolo

On 14.06.2017 13:25, Paolo Bonzini wrote:
> 
> 
> On 14/06/2017 13:18, Thomas Huth wrote:
>> On 08.06.2017 16:18, Thomas Huth wrote:
>>> There does not seem to be any target specific code in these files, so
>>> we can put them into "common-obj" instead of "obj" to compile them only
>>> once for all targets.
>>
>> Self-NACK: balloon.c uses kvm_enabled() which in turn depends on
>> CONFIG_KVM ... and that flag is target-specific, so balloon.o can not be
>> moved to common-obj right now.
>>
>> We should poison CONFIG_KVM for common code ... I'll have a look into
>> that...
> 
> No, your patch is okay.
> 
> #if defined CONFIG_KVM || !defined NEED_CPU_H
> #define kvm_enabled()           (kvm_allowed)
> ...
> #else
> #define kvm_enabled()           (0)
> 
> In other words, kvm_enabled() forces itself to be 0 only in per-target
> files.  This is done mostly to limit the number of required stubs:
> target-independent APIs can be called from compile-once files and must
> be stubbed; target-specific APIs can only be called from per-target
> files, and their calls are culled by the compiler if !CONFIG_KVM.

OK, thanks for the explanation!
... but I now think my patch is still wrong, due to another reason:
numa.o indirectly uses ram_addr_t variables, and these are target
specific, as far as I can see. So at least that file should not be moved
to common-obj-y.

 Thomas