Skip to contentSkip to conversation

Loss of lock drop in qemu/net.c

DISCUSSION Avi Kivity 3 participants 5 messages Dec 16, 2008 – Dec 17, 2008 KVM

lore
Share & tools
lore

Avi Kivity

author
#0 lore raw

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.

Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
#1 lore raw
Quoted 1 line · 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).

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

Regards,

Anthony Liguori

Quoted 2 lines

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

author
#2 lore raw
Quoted 5 lines · Anthony Liguori
Quoted 1 line · 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).

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).

Signature · 1 line
error compiling committee.c: too many arguments to function
#3 lore raw
In reply to Avi Kivity
Quoted 5 lines · Avi Kivity

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.

author
#4 lore raw
Quoted 7 lines · Mark McLoughlin
Quoted 2 lines · Avi Kivity

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.

Signature · 1 line
error compiling committee.c: too many arguments to function