Okay, I have made the following change in dom0:

To disable the transmit path for guest OSes: Edit net_tx_action in arch/xen/drivers/netif/backend/main.c. After the call to netif_schedule_work(), add: make_tx_response(netif, txreq.id, NETIF_RSP_OKAY); netif_put(netif); continue;

compiled and rebooted with the new kernel. booted dom1, removed vif1.0 from the
bridge, gave it it's own ip address, added a static arp entry and pinged away. I
could see the packet counters for dom0 and dom1 climbing rapiding indicating
that dom0 was sending packets, dom1 was receiving packets, but that a packet
sent by dom1 was unable to reach dom0 again. I got the same sort of crashes
after about 10 minutes.

I'm now testing the other half.

James

From: Keir Fraser Sent: Thu 22/07/2004 12:56 PM To: James Harper Cc: Keir Fraser; xen-...@lists.sourceforge.net Subject: Re: [Xen-devel] segfault in VM

It does seem more likely that the network backend driver is to blame -- it's considerably more complicated than the blkdev driver.

Yes, it's basically a point-to-point link. The transmit side on each interface is directly linked to the receive side on the other.

No. dom1.eth0 is implemented by the frontend driver arch/xen/drivers/netif/frontend/main.c dom0.vif* is implemented by arch/xen/drivers/netif/backend/main.c

So they look symmetric to users, but the implementation is not symmetric.

-- Keir