[Qemu-devel] Build currently broken

[Qemu-devel] Build currently broken

[Luiz Capitulino]

 Hi Glauber,

 Very latest Anthony's tree doesn't build for me:

"""
cc1: warnings being treated as errors
/home/lcapitulino/src/rh-internal/qemu-qmp/kvm-all.c:158: error: ‘on_vcpu’ defined but not used
make[1]: *** [kvm-all.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2
"""

 The culprit seems to be 452e475196a3f8b6b96d16bbaca727ebc1278a97 . The
only user of on_vcpu() is protected by #ifdef KVM_CAP_SET_GUEST_DEBUG.

 The patch below fixes it for me.

---

    Fix broken build
    
    The only caller of on_vcpu() is protected by ifdef
    KVM_CAP_SET_GUEST_DEBUG, so protect on_vcpu() too otherwise QEMU
    may to build.
    
    Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>

diff --git a/kvm-all.c b/kvm-all.c
index 824bb4c..70507b1 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -155,15 +155,6 @@ static void kvm_reset_vcpu(void *opaque)
     }
 }
 
-static void on_vcpu(CPUState *env, void (*func)(void *data), void *data)
-{
-    if (env == cpu_single_env) {
-        func(data);
-        return;
-    }
-    abort();
-}
-
 int kvm_irqchip_in_kernel(void)
 {
     return kvm_state->irqchip_in_kernel;
@@ -906,6 +897,15 @@ void kvm_setup_guest_memory(void *start, size_t size)
 }
 
 #ifdef KVM_CAP_SET_GUEST_DEBUG
+static void on_vcpu(CPUState *env, void (*func)(void *data), void *data)
+{
+    if (env == cpu_single_env) {
+        func(data);
+        return;
+    }
+    abort();
+}
+
 struct kvm_sw_breakpoint *kvm_find_sw_breakpoint(CPUState *env,
                                                  target_ulong pc)
 {

[Qemu-devel] Re: Build currently broken

[Anthony Liguori]

Luiz Capitulino wrote:
>  Hi Glauber,
>
>  Very latest Anthony's tree doesn't build for me:
>
> """
> cc1: warnings being treated as errors
> /home/lcapitulino/src/rh-internal/qemu-qmp/kvm-all.c:158: error: ‘on_vcpu’ defined but not used
> make[1]: *** [kvm-all.o] Error 1
> make: *** [subdir-x86_64-softmmu] Error 2
> """
>
>  The culprit seems to be 452e475196a3f8b6b96d16bbaca727ebc1278a97 . The
> only user of on_vcpu() is protected by #ifdef KVM_CAP_SET_GUEST_DEBUG.
>   

When was KVM_CAP_SET_GUEST_DEBUG introduced?

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: Build currently broken

[Luiz Capitulino]

On Wed, 22 Jul 2009 12:58:56 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Luiz Capitulino wrote:
> >  Hi Glauber,
> >
> >  Very latest Anthony's tree doesn't build for me:
> >
> > """
> > cc1: warnings being treated as errors
> > /home/lcapitulino/src/rh-internal/qemu-qmp/kvm-all.c:158: error: ‘on_vcpu’ defined but not used
> > make[1]: *** [kvm-all.o] Error 1
> > make: *** [subdir-x86_64-softmmu] Error 2
> > """
> >
> >  The culprit seems to be 452e475196a3f8b6b96d16bbaca727ebc1278a97 . The
> > only user of on_vcpu() is protected by #ifdef KVM_CAP_SET_GUEST_DEBUG.
> >   
> 
> When was KVM_CAP_SET_GUEST_DEBUG introduced?

 In QEMU you mean?

 The first commit introducing it seems to be
e22a25c9361c44995c9241c24df0e1e2c47a56c8 , but I have no idea
on how this macro and its code are being used.

[Qemu-devel] Re: Build currently broken

[Anthony Liguori]

Luiz Capitulino wrote:
>  In QEMU you mean?
>
>  The first commit introducing it seems to be
> e22a25c9361c44995c9241c24df0e1e2c47a56c8 , but I have no idea
> on how this macro and its code are being used.
>   
No, I was asking when it was introduced in KVM.  We have a minimal set 
of capabilities that we require.  It looks like KVM_CAP_SET_GUEST_DEBUG 
arrived shortly after KVM_CAP_DESTROY_MEMORY_REGION which is our current 
minimum.

Can you send your patch as a top-level patch?

Regards,

Anthony Liguori

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: Build currently broken

[Anthony Liguori]

Glauber Costa wrote:
> On Wed, Jul 22, 2009 at 01:18:29PM -0500, Anthony Liguori wrote:
>   
>> Luiz Capitulino wrote:
>>     
>>>  In QEMU you mean?
>>>
>>>  The first commit introducing it seems to be
>>> e22a25c9361c44995c9241c24df0e1e2c47a56c8 , but I have no idea
>>> on how this macro and its code are being used.
>>>   
>>>       
>> No, I was asking when it was introduced in KVM.  We have a minimal set  
>> of capabilities that we require.  It looks like KVM_CAP_SET_GUEST_DEBUG  
>> arrived shortly after KVM_CAP_DESTROY_MEMORY_REGION which is our current  
>> minimum.
>>     
> How will this minimum change if we start backporting things like memory aliasing
> broken for qemu?
>   

Good question.  I don't know.  I really hate to have all of these #ifdef 
KVM_CAPs all over the place though.

Maybe we should re-examine pulling in kvm header files.

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: Build currently broken

[Glauber Costa]

On Wed, Jul 22, 2009 at 01:18:29PM -0500, Anthony Liguori wrote:
> Luiz Capitulino wrote:
>>  In QEMU you mean?
>>
>>  The first commit introducing it seems to be
>> e22a25c9361c44995c9241c24df0e1e2c47a56c8 , but I have no idea
>> on how this macro and its code are being used.
>>   
> No, I was asking when it was introduced in KVM.  We have a minimal set  
> of capabilities that we require.  It looks like KVM_CAP_SET_GUEST_DEBUG  
> arrived shortly after KVM_CAP_DESTROY_MEMORY_REGION which is our current  
> minimum.
How will this minimum change if we start backporting things like memory aliasing
broken for qemu?

[Qemu-devel] Re: Build currently broken

[Jan Kiszka]

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

Anthony Liguori wrote:
> Glauber Costa wrote:
>> On Wed, Jul 22, 2009 at 01:18:29PM -0500, Anthony Liguori wrote:
>>  
>>> Luiz Capitulino wrote:
>>>    
>>>>  In QEMU you mean?
>>>>
>>>>  The first commit introducing it seems to be
>>>> e22a25c9361c44995c9241c24df0e1e2c47a56c8 , but I have no idea
>>>> on how this macro and its code are being used.
>>>>         
>>> No, I was asking when it was introduced in KVM.  We have a minimal
>>> set  of capabilities that we require.  It looks like
>>> KVM_CAP_SET_GUEST_DEBUG  arrived shortly after
>>> KVM_CAP_DESTROY_MEMORY_REGION which is our current  minimum.
>>>     

That's true, and that's why we have to test for it.

>> How will this minimum change if we start backporting things like
>> memory aliasing
>> broken for qemu?
>>   
> 
> Good question.  I don't know.  I really hate to have all of these #ifdef
> KVM_CAPs all over the place though.
> 
> Maybe we should re-examine pulling in kvm header files.
> 

Yes, I also once discussed this with Avi: We could drop all that
build-time checks if we always carry sufficiently recent headers. Same
is true for qemu-kvm, where the clutter is even worse (as it has much
more features).

Jan

PS: Ceterum censeo we don't need legacy support beyond our current level.


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