[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. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |