[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] segfault in VM

> At this stage, it looks like disabling the receive path for the
> guest os eg netif_be_start_xmit 'goto drop' means that I can ping
> from the guest OS all i like with no crashes. I hope that's the
> right way around to do it...

Yep, an unconditional 'goto drop;' at the start of netif_be_start_xmit
will prevent the guest from ever receiving packets.

How did you do send packets from the guest -- did you poke an ARP
entry, or send broadcast packets?

Anyway - currently sounds like teh bug resides in the most complex
half of the most complex driver. Who'd've thought it? ;-)

> I'm just looking at that procedure,
> how is the ring actually managed - what do all the _prod and _cons
> variables actually represent? And how is synchronisation handled
> between the domains? i notice there is no spinlock in there, is this
> done by the calling function?

Synchronisation between backend and frontend is lock-free --- for each
ring one guy is producer and the other is consumer so they each update
a disjoint set of ring indexes.

Within the backend, there is implicit per-interface locking on
netif_be_start_xmit so we'll never reenter for the same
interface. Then when we batch stuff up for a tasklet we're still okay
because tasklets are guaranteed non-reentrant also.

 -- Keir

This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.