Date: Wed, 02 Feb 2011 08:53:24 -0800 From: Julian Elischer <julian@freebsd.org> To: Monthadar Al Jaberi <monthadar@gmail.com> Cc: freebsd-virtualization@freebsd.org Subject: Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE) Message-ID: <4D498C04.4050809@freebsd.org> In-Reply-To: <4D498978.7040106@freebsd.org> References: <AANLkTik8D_bLwcUKZdBT-kpkJdDXtPTLvAqfUe0cLoSz@mail.gmail.com> <4D484213.6050100@freebsd.org> <AANLkTikJKZLQVA5X2PQs0oT4iFsZYBw7K07kjQTc9iGD@mail.gmail.com> <4D486108.5060805@freebsd.org> <AANLkTi=mk2vfyXJBaK5mV2sBWEj0-RDZneLs%2BXq_c7sb@mail.gmail.com> <4D498978.7040106@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/2/11 8:42 AM, Julian Elischer wrote: > 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 NUL > > 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. oops sent too early. I think you said you had seen it but read it again now that I have explained some of it to you and maybe it will give new insights. The VNET_SYSINIT() code will get called once for every vnet, and the current vnet is set up for you before it calls you. it is also called once when you start a NEW vnet.. this is the place where Marko jumps in because my head is currently full of other stuff from work and I have paged the vimage stuff out to swap.. :-) > >> I still get a panic... >> >> br, >> >> On Tue, Feb 1, 2011 at 8:37 PM, Julian >> Elischer<julian@freebsd.org> 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<julian@freebsd.org> >>>> 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 >>>>>> >>>> >>> >> >> > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D498C04.4050809>