From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 16:42:32 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 78E531065673 for ; Wed, 2 Feb 2011 16:42:32 +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 4DB6B8FC1F for ; Wed, 2 Feb 2011 16:42:32 +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 p12GgTUE056040 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 08:42:31 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D498978.7040106@freebsd.org> Date: Wed, 02 Feb 2011 08:42:32 -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> <4D486108.5060805@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: Wed, 02 Feb 2011 16:42:32 -0000 On 2/2/11 7:06 AM, Monthadar Al Jaberi wrote: > Thanx makes more sense, but I have noticed something weired if you can > shade some light on. > > I added printfs one when the module is first loaded (static int > event_handler(module_t module, int event, void *arg)): > curthread=0xc3f95870 > curthread->td_vnet=0xc3170e00 > curthread->td_ucred=0xc3185d00 > TD_TO_VNET=0 > CRED_TO_VNET=0 > > > And same printf in wtap_ioctl which is called from a user space > program (I am root): > curthread=0xc3f952d0 > curthread->td_vnet=0 > curthread->td_ucred=0xc3185d00 > TD_TO_VNET=0 > CRED_TO_VNET=0 > > > In both cases TD_TO_VNET/CRED_TO_VNET return NULL... shouldn't they > return a pointer same as curthread->td_vnet? Another thing is that in > wtap_ioctl curthread->td_vnet is NULL that depends on where in your code you did the print.. have you read this file? http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt&REV=18 use the 'download' button to get a more readable version. it goes into some of the details of this. especially the initialization or vimage modules. > I still get a panic... > > br, > > On Tue, Feb 1, 2011 at 8:37 PM, Julian Elischer wrote: >> ok here's how it works.. >> >> any place you access a V_xxx variable you need to have the current vnet set. >> so somewhere in your code path to get to that point you have to have done >> CURVNET_SET() and after you have finised on the way out you should do >> CURVNET_RESTORE(). >> >> you can get the vnet from several places: >> >> 1/ as shown below, you can get it from any thread's cred if teh running >> thread is part of a >> process in the jail in question. >> 2/ if you have an ifp pointer, you can use ifp->vnet . I think that's >> right, it's been a while... >> 3/ I believe though I may be wrong (I may be thinking of multi FIBS) >> that it maybe in the socket structure too but don't trust me on that one.. >> check it. >> >> if, like in a timer thread you have access to NONE of those, you have >> several choices.. >> 1/ the caller of the timer may have given you indirect access to it in the >> arg. >> 2/ maybe you juaast have to interate through all the vimages.. to do >> whatever it is that you do >> (that happens in some protocols) >> >> >> 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 >>> >>> >>>>> 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 >>>>> >>> >> > >