From owner-freebsd-virtualization@FreeBSD.ORG Tue Feb 1 19:30:55 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 74C001065696 for ; Tue, 1 Feb 2011 19:30:55 +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 3EED78FC12 for ; Tue, 1 Feb 2011 19:30:54 +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 p11JUqnP050009 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 11:30:53 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D485F6F.80003@freebsd.org> Date: Tue, 01 Feb 2011 11:30:55 -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: <4D484213.6050100@freebsd.org> 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 19:30:55 -0000 On 2/1/11 11:04 AM, Monthadar Al Jaberi wrote: > On Tue, Feb 1, 2011 at 6:25 PM, Julian Elischer wrote: >> 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. > so I cant call if_alloc directly? > >> 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 wtap is based on ath driver code (if_ath.c) which should look like > a real device right? > if_ath.c is not using VNET, as far as I can tell.... > > Currently my module creates a couple of wtaps, which I then create a > corresponding wlan. These wtaps are interconnected together, so no out > world yet... so I dont have struct cdev *dev.... > > Basic idea is my module have a main queue (simulating air) and each > wtap have a rx_task which sends packets up to higher layers, plus > callout timer for generation beacons... > > I will try to use CURVET_SET(...) tomo yes.. I don't mean that you need the clone stuff, just the VNET parts.. > >>> 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 >>> >> > >