[Qemu-devel] buildbot failure in qemu on default_ppc

[Qemu-devel] buildbot failure in qemu on default_ppc

[qemu]

The Buildbot has detected a new failure on builder default_ppc while building qemu.
Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417

Buildbot URL: http://buildbot.b1-systems.de/qemu/

Buildslave for this Build: qemu-ppc.opensuse.org

Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist: 

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Andreas Färber]

Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
> The Buildbot has detected a new failure on builder default_ppc while building qemu.
> Full details are available at:
>  http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
> 
> Buildbot URL: http://buildbot.b1-systems.de/qemu/
> 
> Buildslave for this Build: qemu-ppc.opensuse.org
> 
> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
> Build Source Stamp: [branch master] HEAD
> Blamelist: 
> 
> BUILD FAILED: failed compile

  CC    ppc-softmmu/kvm-all.o
/home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
has incomplete type
/home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
/home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
no member named 'direct_msi'
make[1]: *** [kvm-all.o] Error 1
make: *** [subdir-ppc-softmmu] Error 2

/-F

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

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Anthony Liguori]

On 06/05/2012 08:54 AM, Andreas Färber wrote:
> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>> The Buildbot has detected a new failure on builder default_ppc while building qemu.
>> Full details are available at:
>>   http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>
>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>
>> Buildslave for this Build: qemu-ppc.opensuse.org
>>
>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
>> Build Source Stamp: [branch master] HEAD
>> Blamelist:
>>
>> BUILD FAILED: failed compile
>
>    CC    ppc-softmmu/kvm-all.o
> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
> has incomplete type
> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
> no member named 'direct_msi'
> make[1]: *** [kvm-all.o] Error 1
> make: *** [subdir-ppc-softmmu] Error 2

Aren't GSI and even MSI very x86-centric concepts?   Why is this code in 
kvm-all.c to begin with?

Regards,

Anthony Liguori

>
> /-F
>

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Alexander Graf]

On 05.06.2012, at 02:58, Anthony Liguori wrote:

> On 06/05/2012 08:54 AM, Andreas Färber wrote:
>> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>>> The Buildbot has detected a new failure on builder default_ppc while building qemu.
>>> Full details are available at:
>>>  http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>> 
>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>> 
>>> Buildslave for this Build: qemu-ppc.opensuse.org
>>> 
>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
>>> Build Source Stamp: [branch master] HEAD
>>> Blamelist:
>>> 
>>> BUILD FAILED: failed compile
>> 
>>   CC    ppc-softmmu/kvm-all.o
>> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
>> has incomplete type
>> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
>> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
>> no member named 'direct_msi'
>> make[1]: *** [kvm-all.o] Error 1
>> make: *** [subdir-ppc-softmmu] Error 2
> 
> Aren't GSI and even MSI very x86-centric concepts?   Why is this code in kvm-all.c to begin with?

Weren't GSIs a logical APIC map thing? Either way, MSI is not exactly x86-centric. You can easily do MSI on ppc as well. I'm not sure if the way it's implemented and the way we might one day expose it through an in-kernel [X|M]PIC will be identical though.


Alex

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Anthony Liguori]

On 06/05/2012 09:00 AM, Alexander Graf wrote:
>
> On 05.06.2012, at 02:58, Anthony Liguori wrote:
>
>> On 06/05/2012 08:54 AM, Andreas Färber wrote:
>>> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>>>> The Buildbot has detected a new failure on builder default_ppc while building qemu.
>>>> Full details are available at:
>>>>   http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>>>
>>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>>>
>>>> Buildslave for this Build: qemu-ppc.opensuse.org
>>>>
>>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
>>>> Build Source Stamp: [branch master] HEAD
>>>> Blamelist:
>>>>
>>>> BUILD FAILED: failed compile
>>>
>>>    CC    ppc-softmmu/kvm-all.o
>>> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
>>> has incomplete type
>>> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
>>> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
>>> no member named 'direct_msi'
>>> make[1]: *** [kvm-all.o] Error 1
>>> make: *** [subdir-ppc-softmmu] Error 2
>>
>> Aren't GSI and even MSI very x86-centric concepts?   Why is this code in kvm-all.c to begin with?
>
> Weren't GSIs a logical APIC map thing?

I think GSI is an ACPI concept actually.

> Either way, MSI is not exactly x86-centric. You can easily do MSI on ppc as well.

Okay.

Regards,

Anthony Liguori

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Alexander Graf]

On 05.06.2012, at 03:04, Anthony Liguori wrote:

> On 06/05/2012 09:00 AM, Alexander Graf wrote:
>> 
>> On 05.06.2012, at 02:58, Anthony Liguori wrote:
>> 
>>> On 06/05/2012 08:54 AM, Andreas Färber wrote:
>>>> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>>>>> The Buildbot has detected a new failure on builder default_ppc while building qemu.
>>>>> Full details are available at:
>>>>>  http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>>>> 
>>>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>>>> 
>>>>> Buildslave for this Build: qemu-ppc.opensuse.org
>>>>> 
>>>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
>>>>> Build Source Stamp: [branch master] HEAD
>>>>> Blamelist:
>>>>> 
>>>>> BUILD FAILED: failed compile
>>>> 
>>>>   CC    ppc-softmmu/kvm-all.o
>>>> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
>>>> has incomplete type
>>>> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
>>>> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
>>>> no member named 'direct_msi'
>>>> make[1]: *** [kvm-all.o] Error 1
>>>> make: *** [subdir-ppc-softmmu] Error 2
>>> 
>>> Aren't GSI and even MSI very x86-centric concepts?   Why is this code in kvm-all.c to begin with?
>> 
>> Weren't GSIs a logical APIC map thing?
> 
> I think GSI is an ACPI concept actually.

Sorry, too many acronyms. Yeah, I meant ACPI. Though some map was ACPI and another map was Linux specific. I tend to forget which of the 50 layers between hardware and what you see are actually dictated by whom :).


Alex

Re: [Qemu-devel] buildbot failure in qemu on default_ppc

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On 2012-06-05 02:58, Anthony Liguori wrote:
> On 06/05/2012 08:54 AM, Andreas Färber wrote:
>> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>>> The Buildbot has detected a new failure on builder default_ppc while
>>> building qemu.
>>> Full details are available at:
>>>   http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>>
>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>>
>>> Buildslave for this Build: qemu-ppc.opensuse.org
>>>
>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered
>>> this build
>>> Build Source Stamp: [branch master] HEAD
>>> Blamelist:
>>>
>>> BUILD FAILED: failed compile
>>
>>    CC    ppc-softmmu/kvm-all.o
>> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
>> has incomplete type
>> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
>> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
>> no member named 'direct_msi'
>> make[1]: *** [kvm-all.o] Error 1
>> make: *** [subdir-ppc-softmmu] Error 2
> 
> Aren't GSI and even MSI very x86-centric concepts?   Why is this code in
> kvm-all.c to begin with?

MSI is a PCI thing, and GSI in the context of KVM's in-kernel irqchip is
mostly a historic misnomer. It should have been called VIRQ (virtual
IRQ), and I'm using this term now wherever possible. Any architecture
that will also support in-kernel irqchips with line-based IRQs or irqfd
will have to support this concept as well, thus will most probably use
the generic code in kvm-all.c.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[Qemu-devel] [PATCH] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Jan Kiszka]

On 2012-06-05 02:54, Andreas Färber wrote:
> Am 05.06.2012 01:33, schrieb qemu@buildbot.b1-systems.de:
>> The Buildbot has detected a new failure on builder default_ppc while building qemu.
>> Full details are available at:
>>  http://buildbot.b1-systems.de/qemu/builders/default_ppc/builds/417
>>
>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>
>> Buildslave for this Build: qemu-ppc.opensuse.org
>>
>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
>> Build Source Stamp: [branch master] HEAD
>> Blamelist: 
>>
>> BUILD FAILED: failed compile
> 
>   CC    ppc-softmmu/kvm-all.o
> /home/build/qemu/default_ppc/build/kvm-all.c:66: error: field 'kroute'
> has incomplete type
> /home/build/qemu/default_ppc/build/kvm-all.c: In function 'kvm_init':
> /home/build/qemu/default_ppc/build/kvm-all.c:1289: error: 'KVMState' has
> no member named 'direct_msi'
> make[1]: *** [kvm-all.o] Error 1
> make: *** [subdir-ppc-softmmu] Error 2
> 
> /-F
> 

Sorry for missing this, here is the fix:

-----8<-----

From: Jan Kiszka <jan.kiszka@siemens.com>

A type definition and a KVMState field initialization escaped the
required wrapping with KVM_CAP_IRQ_ROUTING.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 kvm-all.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 489ee53..275dc52 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -62,11 +62,6 @@ typedef struct KVMSlot
 
 typedef struct kvm_dirty_log KVMDirtyLog;
 
-typedef struct KVMMSIRoute {
-    struct kvm_irq_routing_entry kroute;
-    QTAILQ_ENTRY(KVMMSIRoute) entry;
-} KVMMSIRoute;
-
 struct KVMState
 {
     KVMSlot slots[32];
@@ -867,6 +862,11 @@ int kvm_irqchip_set_irq(KVMState *s, int irq, int level)
 }
 
 #ifdef KVM_CAP_IRQ_ROUTING
+typedef struct KVMMSIRoute {
+    struct kvm_irq_routing_entry kroute;
+    QTAILQ_ENTRY(KVMMSIRoute) entry;
+} KVMMSIRoute;
+
 static void set_gsi(KVMState *s, unsigned int gsi)
 {
     s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
@@ -1286,7 +1286,9 @@ int kvm_init(void)
     s->pit_state2 = kvm_check_extension(s, KVM_CAP_PIT_STATE2);
 #endif
 
+#ifdef KVM_CAP_IRQ_ROUTING
     s->direct_msi = (kvm_check_extension(s, KVM_CAP_SIGNAL_MSI) > 0);
+#endif
 
     ret = kvm_arch_init(s);
     if (ret < 0) {
-- 
1.7.3.4

[Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Jan Kiszka]

A type definition and a KVMState field initialization escaped the
required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
dummy kvm_irqchip_release_virq as virtio-pci references (but does not
use) it.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Changes in v2:
 - include the missing kvm_irqchip_release_virq that Ben Collins found

 kvm-all.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 489ee53..4ea7d85 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -62,11 +62,6 @@ typedef struct KVMSlot
 
 typedef struct kvm_dirty_log KVMDirtyLog;
 
-typedef struct KVMMSIRoute {
-    struct kvm_irq_routing_entry kroute;
-    QTAILQ_ENTRY(KVMMSIRoute) entry;
-} KVMMSIRoute;
-
 struct KVMState
 {
     KVMSlot slots[32];
@@ -867,6 +862,11 @@ int kvm_irqchip_set_irq(KVMState *s, int irq, int level)
 }
 
 #ifdef KVM_CAP_IRQ_ROUTING
+typedef struct KVMMSIRoute {
+    struct kvm_irq_routing_entry kroute;
+    QTAILQ_ENTRY(KVMMSIRoute) entry;
+} KVMMSIRoute;
+
 static void set_gsi(KVMState *s, unsigned int gsi)
 {
     s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
@@ -1129,6 +1129,10 @@ static void kvm_init_irq_routing(KVMState *s)
 {
 }
 
+void kvm_irqchip_release_virq(KVMState *s, int virq)
+{
+}
+
 int kvm_irqchip_send_msi(KVMState *s, MSIMessage msg)
 {
     abort();
@@ -1286,7 +1290,9 @@ int kvm_init(void)
     s->pit_state2 = kvm_check_extension(s, KVM_CAP_PIT_STATE2);
 #endif
 
+#ifdef KVM_CAP_IRQ_ROUTING
     s->direct_msi = (kvm_check_extension(s, KVM_CAP_SIGNAL_MSI) > 0);
+#endif
 
     ret = kvm_arch_init(s);
     if (ret < 0) {
-- 
1.7.3.4

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Ben Collins]

Ack: Ben Collins <bcollins@ubuntu.com>

Confirmed that this patch does indeed fix everything for me.

On Jun 5, 2012, at 3:03 PM, Jan Kiszka wrote:

> A type definition and a KVMState field initialization escaped the
> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
> use) it.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> Changes in v2:
> - include the missing kvm_irqchip_release_virq that Ben Collins found
> 
> kvm-all.c |   16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/kvm-all.c b/kvm-all.c
> index 489ee53..4ea7d85 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -62,11 +62,6 @@ typedef struct KVMSlot
> 
> typedef struct kvm_dirty_log KVMDirtyLog;
> 
> -typedef struct KVMMSIRoute {
> -    struct kvm_irq_routing_entry kroute;
> -    QTAILQ_ENTRY(KVMMSIRoute) entry;
> -} KVMMSIRoute;
> -
> struct KVMState
> {
>     KVMSlot slots[32];
> @@ -867,6 +862,11 @@ int kvm_irqchip_set_irq(KVMState *s, int irq, int level)
> }
> 
> #ifdef KVM_CAP_IRQ_ROUTING
> +typedef struct KVMMSIRoute {
> +    struct kvm_irq_routing_entry kroute;
> +    QTAILQ_ENTRY(KVMMSIRoute) entry;
> +} KVMMSIRoute;
> +
> static void set_gsi(KVMState *s, unsigned int gsi)
> {
>     s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
> @@ -1129,6 +1129,10 @@ static void kvm_init_irq_routing(KVMState *s)
> {
> }
> 
> +void kvm_irqchip_release_virq(KVMState *s, int virq)
> +{
> +}
> +
> int kvm_irqchip_send_msi(KVMState *s, MSIMessage msg)
> {
>     abort();
> @@ -1286,7 +1290,9 @@ int kvm_init(void)
>     s->pit_state2 = kvm_check_extension(s, KVM_CAP_PIT_STATE2);
> #endif
> 
> +#ifdef KVM_CAP_IRQ_ROUTING
>     s->direct_msi = (kvm_check_extension(s, KVM_CAP_SIGNAL_MSI) > 0);
> +#endif
> 
>     ret = kvm_arch_init(s);
>     if (ret < 0) {
> -- 
> 1.7.3.4

--
Bluecherry: http://www.bluecherrydvr.com/
SwissDisk : http://www.swissdisk.com/
Ubuntu    : http://www.ubuntu.com/
My Blog   : http://ben-collins.blogspot.com/

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Andreas Färber]

Am 05.06.2012 21:03, schrieb Jan Kiszka:
> A type definition and a KVMState field initialization escaped the
> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
> use) it.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Tested-by: Andreas Färber <afaerber@suse.de>

Thanks,
Andreas

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

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Avi Kivity]

On 06/05/2012 10:03 PM, Jan Kiszka wrote:
> A type definition and a KVMState field initialization escaped the
> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
> use) it.
> 

Thanks, applied.


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

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Jan Kiszka]

On 2012-06-06 10:41, Avi Kivity wrote:
> On 06/05/2012 10:03 PM, Jan Kiszka wrote:
>> A type definition and a KVMState field initialization escaped the
>> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
>> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
>> use) it.
>>
> 
> Thanks, applied.

Please send a pull soon.

Jan

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

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Avi Kivity]

On 06/06/2012 01:31 PM, Jan Kiszka wrote:
> On 2012-06-06 10:41, Avi Kivity wrote:
>> On 06/05/2012 10:03 PM, Jan Kiszka wrote:
>>> A type definition and a KVMState field initialization escaped the
>>> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
>>> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
>>> use) it.
>>>
>> 
>> Thanks, applied.
> 
> Please send a pull soon.

It was posted already, I just forgot to copy you.


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

Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets

[Anthony Liguori]

On 06/06/2012 06:44 PM, Avi Kivity wrote:
> On 06/06/2012 01:31 PM, Jan Kiszka wrote:
>> On 2012-06-06 10:41, Avi Kivity wrote:
>>> On 06/05/2012 10:03 PM, Jan Kiszka wrote:
>>>> A type definition and a KVMState field initialization escaped the
>>>> required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a
>>>> dummy kvm_irqchip_release_virq as virtio-pci references (but does not
>>>> use) it.
>>>>
>>>
>>> Thanks, applied.
>>
>> Please send a pull soon.
>
> It was posted already, I just forgot to copy you.

It's being tested as we type too.

Regards,

Anthony Liguori

>
>