From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 15:06:56 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 1838A106564A; Wed, 2 Feb 2011 15:06:56 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E08D8FC0C; Wed, 2 Feb 2011 15:06:55 +0000 (UTC) Received: by wyf19 with SMTP id 19so61537wyf.13 for ; Wed, 02 Feb 2011 07:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N6V3a+e7DA7dnCjiF/Q/0EchTD7XSHyCC4zdDCtJMrQ=; b=phdOynCYwJjp6ifxTh32USWLaS6s1gDg60kIsORFrnvmtB98mwXaEPG72n/2bt+LQp XRERNnW8oQAz6E5LRJXGHx46MntjrvqBL9/BinOhsMSKBXod3dRf7gqEUJRudeYDaus9 ssIL14MQQumDExk9djIMsPZM63mLhyc2RqHos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fK0edfNjrexIe5a0cgnMsnoe0Mib79Rlq1UVudlC2lhk+Nx1YcNUMDu7nBSeqDPucs DhApty/+WE2429s96OGWKCGiryERONb5n6fSbwz5sK4Mwj89jjywKmbqSv+luP240BNU 60fqyxhyMFgCyBodStWjPTZShS5XXtzrsRJCs= MIME-Version: 1.0 Received: by 10.227.155.83 with SMTP id r19mr9141589wbw.137.1296659212612; Wed, 02 Feb 2011 07:06:52 -0800 (PST) Received: by 10.227.134.137 with HTTP; Wed, 2 Feb 2011 07:06:52 -0800 (PST) In-Reply-To: <4D486108.5060805@freebsd.org> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> Date: Wed, 2 Feb 2011 16:06:52 +0100 Message-ID: From: Monthadar Al Jaberi To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 15:06:56 -0000 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=3D0xc3f95870 curthread->td_vnet=3D0xc3170e00 curthread->td_ucred=3D0xc3185d00 TD_TO_VNET=3D0 CRED_TO_VNET=3D0 And same printf in wtap_ioctl which is called from a user space program (I am root): curthread=3D0xc3f952d0 curthread->td_vnet=3D0 curthread->td_ucred=3D0xc3185d00 TD_TO_VNET=3D0 CRED_TO_VNET=3D0 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 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 s= et. > 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 =A0. =A0 I think tha= t's > right, it's been a while... > 3/ I believe though I may be wrong =A0(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 th= e > 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 >> =A0wrote: >>> >>> 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 =A0was 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. >>> >>> =A0 =A0 =A0 =A0CURVNET_SET(CRED_TO_VNET(cred)); >>> =A0 =A0 =A0 =A0/* find any existing device, or allocate new unit number= */ >>> =A0 =A0 =A0 =A0i =3D clone_create(&tunclones,&tun_cdevsw,&u, dev, 0); >>> =A0 =A0 =A0 =A0[blah] >>> =A0 =A0 =A0 =A0if_clone_create(name, namelen, NULL); >>> =A0 =A0 =A0 =A0CURVNET_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 =3D 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+0x= 25 >>>> witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe >>>> trap(c2fc9abc) at trap+0x195 >>>> calltrap() at calltrap+0x6 >>>> --- trap 0xc, eip =3D 0xc0970999, esp =3D 0xc2fc9afc, ebp =3D 0xc2fc9b= 1c --- >>>> 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+0x= 36 >>>> devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at >>>> devfs_ioctl_f+0x10b >>>> kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20= d >>>> 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 =3D 0x28181203, esp =3D >>>> 0xbfbfec3c, ebp =3D 0xbfbfec58 --- >>>> >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid =3D 0; apic id =3D 00 >>>> fault virtual address =A0 =3D 0x18 >>>> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read, page not pr= esent >>>> instruction pointer =A0 =A0 =3D 0x20:0xc0970999 >>>> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc2fc9afc >>>> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc2fc9b1c >>>> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type = 0x1b >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def3= 2 1, gran 1 >>>> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL = =3D 0 >>>> current process =A0 =A0 =A0 =A0 =3D 1203 (ioctl) >>>> panic: from debugger >>>> cpuid =3D 0 >>>> Uptime: 21s >>>> Physical memory: 495 MB >>>> Dumping 55 MB: 40 24 8 >>>> >>> >> >> > > --=20 //Monthadar Al Jaberi