From owner-freebsd-virtualization@FreeBSD.ORG Tue Feb 1 17:25:39 2011 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7A461065674 for ; Tue, 1 Feb 2011 17:25:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 95A4C8FC1C for ; Tue, 1 Feb 2011 17:25:39 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p11HPaFQ049527 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 09:25:38 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D484213.6050100@freebsd.org> Date: Tue, 01 Feb 2011 09:25:39 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Monthadar Al Jaberi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:25:39 -0000 On 2/1/11 8:40 AM, Monthadar Al Jaberi wrote: > Hi, > > I hope I am on the write place, second try... > > I have written a module that loads fake wifi devices (wtap?) and > distributes packets between them. For now I use route command to route > packets between them from upper layers (TCP,...). > I want to take it to next step and create jails with VNET. I started > reading Julian Elischer's "Vimage: what is it?" and he says that if I > am writing hardware drivers I dont need to make any changes when I > enable VIMAGE option on the kernel, because each one will have their > own stack. > > I can give a more detailed explanation on how my module works. But for > now I get a panic when calling if_alloc() when using option VIMAGE. > > Thank you, while this was true to some extent it i snot 100% true now. during allocation we now try to have separate interface indexes per vimage which means that the setup routines do need to know the current vnet. it looks like wtap_ioctl or wtap_attach should have the following: (copied from the tun driver) this should not be needed from real hardware based drivers as far as I can tell. CURVNET_SET(CRED_TO_VNET(cred)); /* find any existing device, or allocate new unit number */ i = clone_create(&tunclones, &tun_cdevsw, &u, dev, 0); [blah] if_clone_create(name, namelen, NULL); CURVNET_RESTORE(); > > My setup: > FreeBSD Current 201010 guest on VirtualBox on Ubuntu 10.04. > > Kernel page fault with the following non-sleepable locks held: > exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @ > /usr/src/sys/net/if.c:414 > KDB: stack backtrace: > db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a > _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe > trap(c2fc9abc) at trap+0x195 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c --- > ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at > ifindex_alloc_locked+0x19 > if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85 > wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29 > new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b > wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36 > devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at > devfs_ioctl_f+0x10b > kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d > ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134 > syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263 > syscall(c2fc9d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp = > 0xbfbfec3c, ebp = 0xbfbfec58 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0970999 > stack pointer = 0x28:0xc2fc9afc > frame pointer = 0x28:0xc2fc9b1c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1203 (ioctl) > panic: from debugger > cpuid = 0 > Uptime: 21s > Physical memory: 495 MB > Dumping 55 MB: 40 24 8 >