Loss of lock drop in qemu/net.c

Loss of lock drop in qemu/net.c

[Avi Kivity]

hThe recent qemu merged does not allow net.h to include kvm code (due to 
a dependency on cpu.h).  This means I had to drop the 
kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, 
makes the whole thing vulnerable to hotunplug; we need refcounting or 
locking here).

We'll need to find some way to put this back in.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Loss of lock drop in qemu/net.c

[Anthony Liguori]

Avi Kivity wrote:
> hThe recent qemu merged does not allow net.h to include kvm code (due 
> to a dependency on cpu.h).  This means I had to drop the 
> kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, 
> makes the whole thing vulnerable to hotunplug; we need refcounting or 
> locking here).

Why does net.h include cpu.h and why would net.h need kvm code?

Regards,

Anthony Liguori

> We'll need to find some way to put this back in.
>

Re: Loss of lock drop in qemu/net.c

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> hThe recent qemu merged does not allow net.h to include kvm code (due 
>> to a dependency on cpu.h).  This means I had to drop the 
>> kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, 
>> makes the whole thing vulnerable to hotunplug; we need refcounting or 
>> locking here).
>
> Why does net.h include cpu.h and why would net.h need kvm code?
>

I meant net.c -> qemu->kvm.h -> cpu.h.

The code in question is in net.c (in tap_send).

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

Re: Loss of lock drop in qemu/net.c

[Mark McLoughlin]

On Tue, 2008-12-16 at 21:38 +0200, Avi Kivity wrote:
> The recent qemu merged does not allow net.h to include kvm code (due to 
> a dependency on cpu.h).  This means I had to drop the 
> kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, 
> makes the whole thing vulnerable to hotunplug; we need refcounting or 
> locking here).

How can the tap vlan client be affected by hotunplug?

(Dropping the lock from a hotunpluggable PCI device like virtio_net
would be dangerous - even though the removal is done by the monitor in
the I/O thread and so can't happen while the thread is sleeping, the
device isn't actually removed until the guest has acked it with EJ0 and
this would be handled by a vcpu thread)

Cheers,
Mark.

Re: Loss of lock drop in qemu/net.c

[Avi Kivity]

Mark McLoughlin wrote:
> On Tue, 2008-12-16 at 21:38 +0200, Avi Kivity wrote:
>   
>> The recent qemu merged does not allow net.h to include kvm code (due to 
>> a dependency on cpu.h).  This means I had to drop the 
>> kvm_sleep_begin()/kvm_sleep_end() around the packet send (which, btw, 
>> makes the whole thing vulnerable to hotunplug; we need refcounting or 
>> locking here).
>>     
>
> How can the tap vlan client be affected by hotunplug?
>   

It cannot; my mistake.

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