WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] segfault in VM

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] segfault in VM
From: James Harper <JamesH@xxxxxxxxxxxxxxxx>
Date: Thu, 22 Jul 2004 13:49:53 +1000
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 22 Jul 2004 05:01:55 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1BnTkw-0000B5-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1BnTkw-0000B5-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcRvnvJAJogCAD03QU+3+EgJu2KFgg==
Thread-topic: [Xen-devel] segfault in VM
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-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] segfault in VM

> As a first test I have just disabled networking via nics=0 in the config, and running this script in dom1:
> #!/bin/sh
> while [ 1 = 1 ]
> do
>   dd if=/dev/sda1 of=/dev/null bs=1024 count=128K &
>   dd if=/dev/sda1 of=/dev/null bs=1024 skip=256K count=256K
> done
> 
> it tells me 'ioctl 801c6d02 not supported by XL blkif' but that doesn't seem to matter. Anyway, there are no crashes so far so i'm thinking at this stage that the block interface stuff is probably fine and I should now concentrate on the network. Disabling the block stuff will be a huge hassle at this stage so i'll have to let it go for the moment.

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

> I think i need a crash course in how all this hangs together before I can understand what i'm testing... My understanding is as follows:
> 
> packets sent to dom0.vif1.0 appear at dom1.eth0.
> packets sent to dom1.eth0 appear at dom0.vif1.0.

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.

> and that's about it. Are they symmetrical? Is the transmit code for dom0.vif1.0 the same as the transmit code for dom1.eth0? Ditto for receive?

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