[Qemu-devel] [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Qemu-devel] [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

Hi,

This set of patches fixes building qemu-kvm for non KVM targets, as
reported in
http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2984626&group_id=180599

One of the main problem is that we have a tendency to move things from
Makefile.objs to Makefile.target in order to be able to use
TARGET_I386 etc in hw/*.c files. IMHO we need to start clamping down
on this harder and move things into separate files rather than the
#ifdef hacks. Hence this patch fixes the short term problem, but there
is more work to do for the longer term.

Cheers,
Jes

Jes Sorensen (7):
  Only call kvm_set_irqfd() if CONFIG_KVM is defined
  No need for kvm_init() stub as already defined in qemu-kvm.h
  time_drift_fix is x86 only, rather than !ia64
  Build certain drivers for MIPS as well.
  Only export phys_mem create functions for !CONFIG_USER_ONLY builds
  Only treat KVM specific cmdline options for KVM enabled builds
  Only accept -no-hpet for i386 targets

 Makefile.target |    2 ++
 hw/i8259.c      |    2 +-
 hw/virtio-pci.c |    4 ++++
 kvm-stub.c      |    5 -----
 qemu-kvm.h      |    2 ++
 vl.c            |    4 ++++
 6 files changed, 13 insertions(+), 6 deletions(-)

[Qemu-devel] [PATCH 1/7] Only call kvm_set_irqfd() if CONFIG_KVM is defined

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

Only call kvm_set_irqfd() if CONFIG_KVM is defined to avoid breaking
the build for non x86.

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 hw/virtio-pci.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index c3c1fcd..926b8e1 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -431,6 +431,7 @@ static void virtio_pci_guest_notifier_read(void *opaque)
 static int virtio_pci_mask_notifier(PCIDevice *dev, unsigned vector,
                                     void *opaque, int masked)
 {
+#ifdef CONFIG_KVM
     VirtQueue *vq = opaque;
     EventNotifier *notifier = virtio_queue_get_guest_notifier(vq);
     int r = kvm_set_irqfd(dev->msix_irq_entries[vector].gsi,
@@ -447,6 +448,9 @@ static int virtio_pci_mask_notifier(PCIDevice *dev, unsigned vector,
                             NULL, NULL, NULL);
     }
     return 0;
+#else
+    return -ENOSYS;
+#endif
 }
 
 static int virtio_pci_set_guest_notifier(void *opaque, int n, bool assign)
-- 
1.6.6.1

[Qemu-devel] Re: [PATCH 1/7] Only call kvm_set_irqfd() if CONFIG_KVM is defined

[Paolo Bonzini]

On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> Only call kvm_set_irqfd() if CONFIG_KVM is defined to avoid breaking
> the build for non x86.

You can just add a stub to kvm-stub.c that returns -ENOSYS.

Paolo

[Qemu-devel] Re: [PATCH 1/7] Only call kvm_set_irqfd() if CONFIG_KVM is defined

[Jes Sorensen]

On 06/15/10 15:31, Paolo Bonzini wrote:
> On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>
>> Only call kvm_set_irqfd() if CONFIG_KVM is defined to avoid breaking
>> the build for non x86.
> 
> You can just add a stub to kvm-stub.c that returns -ENOSYS.
> 
> Paolo

It's more than that, the code also uses bits in the msix code that isn't
globally available.

Cheers,
Jes

[Qemu-devel] Re: [PATCH 1/7] Only call kvm_set_irqfd() if CONFIG_KVM is defined

[Paolo Bonzini]

On 06/15/2010 03:40 PM, Jes Sorensen wrote:
> On 06/15/10 15:31, Paolo Bonzini wrote:
>> On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
>>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>>
>>> Only call kvm_set_irqfd() if CONFIG_KVM is defined to avoid breaking
>>> the build for non x86.
>>
>> You can just add a stub to kvm-stub.c that returns -ENOSYS.
>>
>> Paolo
>
> It's more than that, the code also uses bits in the msix code that isn't
> globally available.

I see now.  BTW, my eventnotifier series conflicts with this part of 
qemu-kvm, so it's probably better if I work that series out in qemu-kvm 
first and then upstream.  As I would touch this code anyway, I think 
your patch is fine even if it were be only a stopgap measure.

Maybe the right fix, which I could include in my series, is to change 
kvm_set_irqfd's calling convention to be like this:

     int r = kvm_set_irqfd(&dev->msix_irq_entries[vector],
                           event_notifier_get_fd(notifier),
                           !masked);

and extract the gsi in the function.  Michael, does this make any sense?

Paolo

[Qemu-devel] Re: [PATCH 1/7] Only call kvm_set_irqfd() if CONFIG_KVM is defined

[Michael S. Tsirkin]

On Tue, Jun 15, 2010 at 03:48:50PM +0200, Paolo Bonzini wrote:
> On 06/15/2010 03:40 PM, Jes Sorensen wrote:
>> On 06/15/10 15:31, Paolo Bonzini wrote:
>>> On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
>>>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>>>
>>>> Only call kvm_set_irqfd() if CONFIG_KVM is defined to avoid breaking
>>>> the build for non x86.
>>>
>>> You can just add a stub to kvm-stub.c that returns -ENOSYS.
>>>
>>> Paolo
>>
>> It's more than that, the code also uses bits in the msix code that isn't
>> globally available.
>
> I see now.  BTW, my eventnotifier series conflicts with this part of  
> qemu-kvm, so it's probably better if I work that series out in qemu-kvm  
> first and then upstream.  As I would touch this code anyway, I think  
> your patch is fine even if it were be only a stopgap measure.
>
> Maybe the right fix, which I could include in my series, is to change  
> kvm_set_irqfd's calling convention to be like this:
>
>     int r = kvm_set_irqfd(&dev->msix_irq_entries[vector],
>                           event_notifier_get_fd(notifier),
>                           !masked);
>
> and extract the gsi in the function.  Michael, does this make any sense?
>
> Paolo

I'm fine with this change.

[Qemu-devel] [PATCH 2/7] No need for kvm_init() stub as already defined in qemu-kvm.h

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

No need for kvm_init() stub in kvm-stub.c as already defined in
qemu-kvm.h

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 kvm-stub.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/kvm-stub.c b/kvm-stub.c
index 7be5f5d..645fa1d 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -57,11 +57,6 @@ int kvm_check_extension(KVMState *s, unsigned int extension)
     return 0;
 }
 
-int kvm_init(int smp_cpus)
-{
-    return -ENOSYS;
-}
-
 void kvm_flush_coalesced_mmio_buffer(void)
 {
 }
-- 
1.6.6.1

[Qemu-devel] Re: [PATCH 2/7] No need for kvm_init() stub as already defined in qemu-kvm.h

[Paolo Bonzini]

On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> No need for kvm_init() stub in kvm-stub.c as already defined in
> qemu-kvm.h

Why not keep the other one and match upstream?  Instead, I'd remove this 
one and move kvm_inject_x86_mce to kvm-stub.c.

Files that upstream compiles only once will be compiled only without 
CONFIG_KVM, and will always call the stubs if these are in qemu-kvm.h.

Paolo

[Qemu-devel] Re: [PATCH 2/7] No need for kvm_init() stub as already defined in qemu-kvm.h

[Jes Sorensen]

On 06/15/10 15:34, Paolo Bonzini wrote:
> On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>
>> No need for kvm_init() stub in kvm-stub.c as already defined in
>> qemu-kvm.h
> 
> Why not keep the other one and match upstream?  Instead, I'd remove this
> one and move kvm_inject_x86_mce to kvm-stub.c.
> 
> Files that upstream compiles only once will be compiled only without
> CONFIG_KVM, and will always call the stubs if these are in qemu-kvm.h.

You're right, time for a v3 of the patch....

Cheers,
Jes

[Qemu-devel] [PATCH 3/7] time_drift_fix is x86 only, rather than !ia64

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

time_drift_fix is x86 only, rather than !ia64, to allow the code to
build for other archs, like MIPS.

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 hw/i8259.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/i8259.c b/hw/i8259.c
index a8ae069..e89d831 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -237,7 +237,7 @@ int pic_read_irq(PicState2 *s)
     if (irq >= 0) {
 
         pic_intack(&s->pics[0], irq);
-#ifndef TARGET_IA64
+#ifdef TARGET_I386
 	if (time_drift_fix && irq == 0) {
 	    extern int64_t timer_acks, timer_ints_to_push;
 	    timer_acks++;
-- 
1.6.6.1

[Qemu-devel] [PATCH 4/7] Build certain drivers for MIPS as well.

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

pcspk.o i8254.o acpi.o acpi_piix4.o are all required for MIPS as well,
add them to Makefile.target accordingly.

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 Makefile.target |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index a0e9747..26d1d93 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -245,6 +245,8 @@ obj-ppc-$(CONFIG_KVM) += kvm_ppc.o
 obj-ppc-$(CONFIG_FDT) += device_tree.o
 
 obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o mips_mipssim.o
+obj-mips-y += pcspk.o i8254.o
+obj-mips-y += acpi.o acpi_piix4.o
 obj-mips-y += mips_addr.o mips_timer.o mips_int.o
 obj-mips-y += vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
-- 
1.6.6.1

[Qemu-devel] [PATCH 5/7] Only export phys_mem create functions for !CONFIG_USER_ONLY builds

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

Only export phys_mem create functions for !CONFIG_USER_ONLY builds

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 qemu-kvm.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/qemu-kvm.h b/qemu-kvm.h
index 6f6c6d8..9adbc58 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -812,6 +812,7 @@ void qemu_kvm_cpuid_on_env(CPUState *env);
 void kvm_inject_interrupt(CPUState *env, int mask);
 void kvm_update_after_sipi(CPUState *env);
 void kvm_update_interrupt_request(CPUState *env);
+#ifndef CONFIG_USER_ONLY
 void *kvm_cpu_create_phys_mem(target_phys_addr_t start_addr, unsigned long size,
                               int log, int writable);
 
@@ -819,6 +820,7 @@ void kvm_cpu_destroy_phys_mem(target_phys_addr_t start_addr,
                               unsigned long size);
 void kvm_qemu_log_memory(target_phys_addr_t start, target_phys_addr_t size,
                          int log);
+#endif
 int kvm_qemu_create_memory_alias(uint64_t phys_start, uint64_t len,
                                  uint64_t target_phys);
 int kvm_qemu_destroy_memory_alias(uint64_t phys_start);
-- 
1.6.6.1

[Qemu-devel] Re: [PATCH 5/7] Only export phys_mem create functions for !CONFIG_USER_ONLY builds

[Paolo Bonzini]

On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> Only export phys_mem create functions for !CONFIG_USER_ONLY builds
>
> Signed-off-by: Jes Sorensen<Jes.Sorensen@redhat.com>
> ---
>   qemu-kvm.h |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/qemu-kvm.h b/qemu-kvm.h
> index 6f6c6d8..9adbc58 100644
> --- a/qemu-kvm.h
> +++ b/qemu-kvm.h
> @@ -812,6 +812,7 @@ void qemu_kvm_cpuid_on_env(CPUState *env);
>   void kvm_inject_interrupt(CPUState *env, int mask);
>   void kvm_update_after_sipi(CPUState *env);
>   void kvm_update_interrupt_request(CPUState *env);
> +#ifndef CONFIG_USER_ONLY
>   void *kvm_cpu_create_phys_mem(target_phys_addr_t start_addr, unsigned long size,
>                                 int log, int writable);
>
> @@ -819,6 +820,7 @@ void kvm_cpu_destroy_phys_mem(target_phys_addr_t start_addr,
>                                 unsigned long size);
>   void kvm_qemu_log_memory(target_phys_addr_t start, target_phys_addr_t size,
>                            int log);
> +#endif
>   int kvm_qemu_create_memory_alias(uint64_t phys_start, uint64_t len,
>                                    uint64_t target_phys);
>   int kvm_qemu_destroy_memory_alias(uint64_t phys_start);

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

[Qemu-devel] [PATCH 6/7] Only treat KVM specific cmdline options for KVM enabled builds

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

Only treat KVM specific cmdline options for KVM enabled builds. This
fixes build breakage for target MIPS etc.

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 vl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index 9e9c176..e4a9aa9 100644
--- a/vl.c
+++ b/vl.c
@@ -3264,6 +3264,7 @@ int main(int argc, char **argv, char **envp)
 	    case QEMU_OPTION_no_kvm:
 		kvm_allowed = 0;
 		break;
+#ifdef CONFIG_KVM
 	    case QEMU_OPTION_no_kvm_irqchip: {
 		kvm_irqchip = 0;
 		kvm_pit = 0;
@@ -3281,6 +3282,7 @@ int main(int argc, char **argv, char **envp)
 		kvm_nested = 1;
 		break;
 	    }
+#endif
 #if defined(TARGET_I386) || defined(TARGET_X86_64) || defined(TARGET_IA64) || defined(__linux__)
             case QEMU_OPTION_pcidevice:
 		if (assigned_devices_index >= MAX_DEV_ASSIGN_CMDLINE) {
-- 
1.6.6.1

[Qemu-devel] [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jes.Sorensen]

From: Jes Sorensen <Jes.Sorensen@redhat.com>

Only accept -no-hpet for i386 targets

Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
 vl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index e4a9aa9..1977409 100644
--- a/vl.c
+++ b/vl.c
@@ -3328,9 +3328,11 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_no_acpi:
                 acpi_enabled = 0;
                 break;
+#ifdef TARGET_I386
             case QEMU_OPTION_no_hpet:
                 no_hpet = 1;
                 break;
+#endif
             case QEMU_OPTION_balloon:
                 if (balloon_parse(optarg) < 0) {
                     fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
-- 
1.6.6.1

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jan Kiszka]

Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> 
> Only accept -no-hpet for i386 targets
> 
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
> ---
>  vl.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index e4a9aa9..1977409 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3328,9 +3328,11 @@ int main(int argc, char **argv, char **envp)
>              case QEMU_OPTION_no_acpi:
>                  acpi_enabled = 0;
>                  break;
> +#ifdef TARGET_I386
>              case QEMU_OPTION_no_hpet:
>                  no_hpet = 1;
>                  break;
> +#endif
>              case QEMU_OPTION_balloon:
>                  if (balloon_parse(optarg) < 0) {
>                      fprintf(stderr, "Unknown -balloon argument %s\n", optarg);

Upstream carries no-hpet unconditionally now. I guess you need to clean
up a different merge artifact.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jes Sorensen]

On 06/15/10 14:20, Jan Kiszka wrote:
>> @@ -3328,9 +3328,11 @@ int main(int argc, char **argv, char **envp)
>>              case QEMU_OPTION_no_acpi:
>>                  acpi_enabled = 0;
>>                  break;
>> +#ifdef TARGET_I386
>>              case QEMU_OPTION_no_hpet:
>>                  no_hpet = 1;
>>                  break;
>> +#endif
>>              case QEMU_OPTION_balloon:
>>                  if (balloon_parse(optarg) < 0) {
>>                      fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
> 
> Upstream carries no-hpet unconditionally now. I guess you need to clean
> up a different merge artifact.

Upstream seems to have removed the TARGET_I386 around 'int no_hpet = 0;'
but to be honest, I think the correct solution is to not expose no_hpet
to non x86 targets in upstream.

Cheers,
Jes

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jan Kiszka]

Jes Sorensen wrote:
> On 06/15/10 14:20, Jan Kiszka wrote:
>>> @@ -3328,9 +3328,11 @@ int main(int argc, char **argv, char **envp)
>>>              case QEMU_OPTION_no_acpi:
>>>                  acpi_enabled = 0;
>>>                  break;
>>> +#ifdef TARGET_I386
>>>              case QEMU_OPTION_no_hpet:
>>>                  no_hpet = 1;
>>>                  break;
>>> +#endif
>>>              case QEMU_OPTION_balloon:
>>>                  if (balloon_parse(optarg) < 0) {
>>>                      fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
>> Upstream carries no-hpet unconditionally now. I guess you need to clean
>> up a different merge artifact.
> 
> Upstream seems to have removed the TARGET_I386 around 'int no_hpet = 0;'
> but to be honest, I think the correct solution is to not expose no_hpet
> to non x86 targets in upstream.

Then I would suggest to address this upstream first. The goal should be
to keep the diff low.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jes Sorensen]

On 06/15/10 14:37, Jan Kiszka wrote:
>> Upstream seems to have removed the TARGET_I386 around 'int no_hpet = 0;'
>> but to be honest, I think the correct solution is to not expose no_hpet
>> to non x86 targets in upstream.
> 
> Then I would suggest to address this upstream first. The goal should be
> to keep the diff low.

I agree, I'll send out an updated diff in a minute to make qemu-kvm
closer to qemu and then look at option exposure in qemu afterwards.

Cheers,
Jes

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Paolo Bonzini]

On 06/15/2010 01:04 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> Only accept -no-hpet for i386 targets
>
> Signed-off-by: Jes Sorensen<Jes.Sorensen@redhat.com>
> ---
>   vl.c |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index e4a9aa9..1977409 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3328,9 +3328,11 @@ int main(int argc, char **argv, char **envp)
>               case QEMU_OPTION_no_acpi:
>                   acpi_enabled = 0;
>                   break;
> +#ifdef TARGET_I386
>               case QEMU_OPTION_no_hpet:
>                   no_hpet = 1;
>                   break;
> +#endif
>               case QEMU_OPTION_balloon:
>                   if (balloon_parse(optarg)<  0) {
>                       fprintf(stderr, "Unknown -balloon argument %s\n", optarg);

This can alternatively be made to match upstream by just removing the 
#ifdef on no_hpet's declaration.

Not saying that -no-hpet makes any sense on non-i386 targets, mind, but 
it seems pointless to deviate from upstream.

Paolo

[Qemu-devel] Re: [PATCH 7/7] Only accept -no-hpet for i386 targets

[Jes Sorensen]

On 06/15/10 15:38, Paolo Bonzini wrote:
> This can alternatively be made to match upstream by just removing the
> #ifdef on no_hpet's declaration.
> 
> Not saying that -no-hpet makes any sense on non-i386 targets, mind, but
> it seems pointless to deviate from upstream.
> 
> Paolo

Fixed in v2 of the patchset.

Jes

[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Avi Kivity]

On 06/15/2010 02:04 PM, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>
> Hi,
>
> This set of patches fixes building qemu-kvm for non KVM targets, as
> reported in
> http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2984626&group_id=180599
>
> One of the main problem is that we have a tendency to move things from
> Makefile.objs to Makefile.target in order to be able to use
> TARGET_I386 etc in hw/*.c files. IMHO we need to start clamping down
> on this harder and move things into separate files rather than the
> #ifdef hacks. Hence this patch fixes the short term problem, but there
> is more work to do for the longer term.
>    

It's the other way round.  Upstream keeps moving stuff out of 
Makefile.target, and I move them back during merges, because the only 
thing I can think of during a merge is "how quickly can I complete this 
merge".

Thanks for tackling this.


-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Avi Kivity]

On 06/15/2010 03:04 PM, Avi Kivity wrote:
> On 06/15/2010 02:04 PM, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>
>> Hi,
>>
>> This set of patches fixes building qemu-kvm for non KVM targets, as
>> reported in
>> http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2984626&group_id=180599 
>>
>>
>> One of the main problem is that we have a tendency to move things from
>> Makefile.objs to Makefile.target in order to be able to use
>> TARGET_I386 etc in hw/*.c files. IMHO we need to start clamping down
>> on this harder and move things into separate files rather than the
>> #ifdef hacks. Hence this patch fixes the short term problem, but there
>> is more work to do for the longer term.
>
> It's the other way round.  Upstream keeps moving stuff out of 
> Makefile.target, and I move them back during merges, because the only 
> thing I can think of during a merge is "how quickly can I complete 
> this merge".
>
> Thanks for tackling this.
>

Oh, I though you actually moved things back.

Anyway,

Reviewed-by: Avi Kivity <avi@redhat.com>


-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Jes Sorensen]

On 06/15/10 14:04, Avi Kivity wrote:
> It's the other way round.  Upstream keeps moving stuff out of
> Makefile.target, and I move them back during merges, because the only
> thing I can think of during a merge is "how quickly can I complete this
> merge".
> 
> Thanks for tackling this.

I see. I found at least some of the cases I was tackling was because
things had moved from .objs to .target because of the TARGET_I386
checks. Trying to use TARGET_I386 in a file that is listed in
Makefile.objs causes nasty warnings.

I would very much like it if we can be more strict not allowing such
changes without a very strong reason in the future :)

Part of the problem is of course that there are no easy ways to check
for the presence of say HPET since we don't have CONFIG_HPET so
TARGET_I386 becomes the easy way :(

Cheers,
Jes

[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Juan Quintela]

Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 06/15/10 14:04, Avi Kivity wrote:
>> It's the other way round.  Upstream keeps moving stuff out of
>> Makefile.target, and I move them back during merges, because the only
>> thing I can think of during a merge is "how quickly can I complete this
>> merge".
>> 
>> Thanks for tackling this.
>
> I see. I found at least some of the cases I was tackling was because
> things had moved from .objs to .target because of the TARGET_I386
> checks. Trying to use TARGET_I386 in a file that is listed in
> Makefile.objs causes nasty warnings.
>
> I would very much like it if we can be more strict not allowing such
> changes without a very strong reason in the future :)
>
> Part of the problem is of course that there are no easy ways to check
> for the presence of say HPET since we don't have CONFIG_HPET so
> TARGET_I386 becomes the easy way :(

On my hpet removal patches, the important bit was that I enabled
#define CONFIG_HPET 1

in C land, that makes it easy to do this kind of tests.  As it is today,
it is very difficult to test for a feature, as we only have TARGET_*
defines.

Instead of CONFIG_HPET, we have TARGET_I386.

Later, Juan.

[Qemu-devel] Re: [PATCH 0/7] Fix building qemu-kvm for non KVM target

[Jes Sorensen]

On 06/15/10 15:42, Juan Quintela wrote:
> On my hpet removal patches, the important bit was that I enabled
> #define CONFIG_HPET 1
> 
> in C land, that makes it easy to do this kind of tests.  As it is today,
> it is very difficult to test for a feature, as we only have TARGET_*
> defines.
> 
> Instead of CONFIG_HPET, we have TARGET_I386.

I totally agree, and I'd like to see things like HPET becoming config
options. Even for I386 builds, it may not be everybody who wants to
build it in.

Cheers,
Jes