From owner-freebsd-virtualization@FreeBSD.ORG Mon Jan 31 11:07:12 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 E71C410656A4 for ; Mon, 31 Jan 2011 11:07:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5DB58FC24 for ; Mon, 31 Jan 2011 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0VB7C7g091935 for ; Mon, 31 Jan 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0VB7ChF091933 for freebsd-virtualization@FreeBSD.org; Mon, 31 Jan 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Jan 2011 11:07:12 GMT Message-Id: <201101311107.p0VB7ChF091933@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-virtualization@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-virtualization@FreeBSD.org 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: Mon, 31 Jan 2011 11:07:13 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/152047 virtualization[vimage] [panic] TUN\TAP under jail with vimage crashe o kern/148155 virtualization[vimage] Kernel panic with PF/IPFilter + VIMAGE kernel a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail a kern/141696 virtualization[rum] [panic] rum(4)+ vimage = kernel panic 5 problems total. From owner-freebsd-virtualization@FreeBSD.ORG Tue Feb 1 16:40:20 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 AF101106564A for ; Tue, 1 Feb 2011 16:40:20 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 469238FC13 for ; Tue, 1 Feb 2011 16:40:19 +0000 (UTC) Received: by fxm16 with SMTP id 16so7256832fxm.13 for ; Tue, 01 Feb 2011 08:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=DcnXUylJ0+vSg6dyG1Dq/aMvnX3tEwsp5LlYolUTwBo=; b=C8jBOU0CTSMR2uSXKF0ybX29z3Vafst+5mEOCLBlQcSTJh1I06RI1lj1HnFYNNjGSm 49J1oLw7Exy/rvBoDGeFtVxPtCKD1h83sPHTJ//hmAEm52u2qecAUDxKHZEPbp/nD0LP 01h8xW24fqOp4Wq+QYHM1cn1mwit6hvUhzPSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qRfYcDILF3FXb2IdI6hulzUstVmgcSVZeMLUK4N8N2FtWVZ3ThZVrzopynAbv+zn1f QCFaf4Tx3zx1GyclVB7pT82NjdOwiCMQ0UTlfr4yDSYFzQ7lGJc0vAWS9GjEpmltCMgS VOAcT3DVULg4XkbtwRh2ui0HxCHpSr1JGr44w= MIME-Version: 1.0 Received: by 10.223.98.197 with SMTP id r5mr2871997fan.68.1296578419080; Tue, 01 Feb 2011 08:40:19 -0800 (PST) Received: by 10.223.146.198 with HTTP; Tue, 1 Feb 2011 08:40:19 -0800 (PST) Date: Tue, 1 Feb 2011 17:40:19 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 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 16:40:20 -0000 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, 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 -- //Monthadar Al Jaberi 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 > From owner-freebsd-virtualization@FreeBSD.ORG Tue Feb 1 19:09:40 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 7E1B7106566B; Tue, 1 Feb 2011 19:09:40 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DFBA38FC12; Tue, 1 Feb 2011 19:09:39 +0000 (UTC) Received: by wwf26 with SMTP id 26so7113940wwf.31 for ; Tue, 01 Feb 2011 11:09:38 -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=bV2feYdTEC6O11oZX/VA6nbkqBw9UktPM2qISlgZZc8=; b=piUTj3b8uxOMub4BKC6pS+hG2IKi2tnVx1fUc/fO/P0X/2tGGpayeZMvBFmcH7EH0k /MPnT8b6aLwjtqu5ouEKPqwNz07nstxlqfcc6yHyuCZUl8Ig7pByHaS6AuqDTQ50Owa8 NhXYrZP4U0jt51SUUM37IpYjpuaLaB7/YQRD0= 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=F7egkw+PoxTD/axdlT4T+W8t0ycInU2TQfaHrVdxxdo5MALu4FuKAy7AgY4KYYlDje 2Zo5pem4Wt2IE9X3FoIQb4RDCps5gkiEoQrazbKgZrxv2sW8xbSjLaJI3QPLs6AiUR2o jfDQv1qV+1A84rOyuJ8qmwztftddhSJABBZNI= MIME-Version: 1.0 Received: by 10.227.153.21 with SMTP id i21mr5806858wbw.50.1296587095183; Tue, 01 Feb 2011 11:04:55 -0800 (PST) Received: by 10.227.134.137 with HTTP; Tue, 1 Feb 2011 11:04:54 -0800 (PST) In-Reply-To: <4D484213.6050100@freebsd.org> References: <4D484213.6050100@freebsd.org> Date: Tue, 1 Feb 2011 20:04:54 +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: Tue, 01 Feb 2011 19:09:40 -0000 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 =A0was true to some extent it i snot 100% true now. > during allocation we now try to have separate interface indexes per vimag= e > 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 ca= n > 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+0x2= 6 >> kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2= a >> _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 =3D 0xc0970999, esp =3D 0xc2fc9afc, ebp =3D 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 =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 pres= ent >> 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 0x= 1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def32 = 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 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 >>> >> > > From owner-freebsd-virtualization@FreeBSD.ORG Tue Feb 1 19:37:44 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 C3BD21065672 for ; Tue, 1 Feb 2011 19:37:44 +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 818FF8FC18 for ; Tue, 1 Feb 2011 19:37:44 +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 p11JbfGv050067 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Feb 2011 11:37:43 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D486108.5060805@freebsd.org> Date: Tue, 01 Feb 2011 11:37:44 -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:37:44 -0000 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 >>> >> > > 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 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 >>>>> >>> >> > > From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 16:53:24 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 0B5B1106566B for ; Wed, 2 Feb 2011 16:53:24 +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 BD61A8FC18 for ; Wed, 2 Feb 2011 16:53:23 +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 p12GrLLd056083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 08:53:22 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D498C04.4050809@freebsd.org> Date: Wed, 02 Feb 2011 08:53:24 -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> <4D498978.7040106@freebsd.org> In-Reply-To: <4D498978.7040106@freebsd.org> 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:53:24 -0000 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 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 >>>>>> >>>> >>> >> >> > > _______________________________________________ > 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" > From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 17:15:07 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 02A99106566B for ; Wed, 2 Feb 2011 17:15:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id A2DE38FC15 for ; Wed, 2 Feb 2011 17:15:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0B22541C650; Wed, 2 Feb 2011 18:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id HBGFyidulE3H; Wed, 2 Feb 2011 18:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 8963C41C67E; Wed, 2 Feb 2011 18:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 727D04448F3; Wed, 2 Feb 2011 17:12:55 +0000 (UTC) Date: Wed, 2 Feb 2011 17:12:54 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110202164827.I80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD virtualization mailing list 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 17:15:07 -0000 On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: Hi, > 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 Try to load it from laoder on boot; I think that should work as we are setting the curvent for the kernel startup. The problem you are seeing is a bug in the current implementation that you cannot add any physical network interface after the kernel started. This applies to cardbus/usb/... as well as any kind of ethernet interface, so a kldload igb should yield it as well. The fix for that is easy and hard at the same time: A) either touch all drivers B) or touch all cloned interfaces and change 3 common lines. or try to make cloners aware of vimages. Solution B) is sitting in perforce with the entire stuff that it depends on and was started with CH=179022,179255 but not limited to that if you want to have a peek. What you certainly can do locally to your driver for now is to make a change like this: +#ifdef VIMAGE + CURVNET_SET(vnet0); +#endif ifp = if_alloc(IFT_ETHER); +#ifdef VIMAGE + CURVNET_RESTORE(); +#endif It's the type A) kind of change from above that will break eventually in the future. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 17:30:54 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 1039E106566B for ; Wed, 2 Feb 2011 17:30:54 +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 D05948FC12 for ; Wed, 2 Feb 2011 17:30:53 +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 p12HUpR9056217 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 09:30:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4994CE.2090209@freebsd.org> Date: Wed, 02 Feb 2011 09:30:54 -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: "Bjoern A. Zeeb" References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110202164827.I80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD virtualization mailing list 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 17:30:54 -0000 On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: > On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: > > Hi, > >> 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 > > Try to load it from laoder on boot; I think that should work as we are > setting the curvent for the kernel startup. > > The problem you are seeing is a bug in the current implementation that > you cannot add any physical network interface after the kernel started. > This applies to cardbus/usb/... as well as any kind of ethernet > interface, so a kldload igb should yield it as well. > > The fix for that is easy and hard at the same time: > A) either touch all drivers > B) or touch all cloned interfaces and change 3 common lines. > or try to make cloners aware of vimages. > > Solution B) is sitting in perforce with the entire stuff that it > depends > on and was started with CH=179022,179255 but not limited to that if you > want to have a peek. > > What you certainly can do locally to your driver for now is to make a > change like this: > > +#ifdef VIMAGE > + CURVNET_SET(vnet0); > +#endif > ifp = if_alloc(IFT_ETHER); > +#ifdef VIMAGE > + CURVNET_RESTORE(); > +#endif > you don't really need the #ifdef except for readability as CURVNET_XXX ar enot defined for !vnet > It's the type A) kind of change from above that will break eventually > in the future. > > /bz > From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 18:05:41 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 D6034106566B; Wed, 2 Feb 2011 18:05:41 +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 147C98FC0A; Wed, 2 Feb 2011 18:05:40 +0000 (UTC) Received: by wyf19 with SMTP id 19so242021wyf.13 for ; Wed, 02 Feb 2011 10:05:40 -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=m0Sr9E64CydevIrSiYAcJv/aeTNe312l8Z6ogU1n1d4=; b=E+vJhQVyXSPaByUtGlrGl7dlLWmGMq9ayhh1YlY66OszqkF1mUeOM16BGgJ5TGmGQ+ TcM5jfYTm3NOeLkLCSyOCBZEPTJNmIYZo5Nayv9EN9U4QKzUFQeB4qJLsawD3GAzQ/Rs dKDvaSAULRTuau+6ZToZ+jQS3A5vR6p6ShRhE= 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=dcMM8f0dIJqvsaaWdHDsEqrJKGqzLwtSZzV55NcsbBhu9gnD5KQ+ssOS5bfhr1ynnE tTFkFQ2DsUgiQbjKIosuVbYY+IPpAO4KylpA0NVOg6Kfz0y7kuUSbSLbioJT/x/e8XUP mY2YlJw8Y7NubHLa0pG1C6IpjSwDXecx76hN8= MIME-Version: 1.0 Received: by 10.227.129.17 with SMTP id m17mr9455506wbs.79.1296669939819; Wed, 02 Feb 2011 10:05:39 -0800 (PST) Received: by 10.227.134.137 with HTTP; Wed, 2 Feb 2011 10:05:39 -0800 (PST) In-Reply-To: <4D4994CE.2090209@freebsd.org> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> Date: Wed, 2 Feb 2011 19:05:39 +0100 Message-ID: From: Monthadar Al Jaberi To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , FreeBSD virtualization mailing list 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 18:05:42 -0000 I just tried something that seems to work, but please dont hit me ^^;;; in wtap_ioctl I assigned curthread->td_vnet myself to point to a VNET (saved it when the module first loaded) (I have not created any jails yet)... and it works... I didnt put any CURVNET macros... my assumption is that if ath drivers dont use VNET I shouldnt :P What is wrong with this hack? br, P.S. I have printed "porting to vnet" text to have it always at hand, but its a bit hard for me... doing my best. On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer wrote: > On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: >> >> On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: >> >> Hi, >> >>> 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 >> >> Try to load it from laoder on boot; I think that should work as we are >> setting the curvent for the kernel startup. >> >> The problem you are seeing is a bug in the current implementation that >> you cannot add any physical network interface after the kernel started. >> This applies to cardbus/usb/... as well as any kind of ethernet >> interface, so a kldload igb should yield it as well. >> >> The fix for that is easy and hard at the same time: >> A) either touch all drivers >> B) or touch all cloned interfaces and change 3 common lines. >> =A0 or try to make cloners aware of vimages. >> >> Solution B) is sitting in perforce with the entire stuff that it depends >> on and was started with CH=3D179022,179255 but not limited to that if yo= u >> want to have a peek. >> >> What you certainly can do locally to your driver for now is to make a >> change like this: >> >> +#ifdef VIMAGE >> + =A0 =A0 =A0 CURVNET_SET(vnet0); >> +#endif >> =A0 =A0 =A0 =A0ifp =3D if_alloc(IFT_ETHER); >> +#ifdef VIMAGE >> + =A0 =A0 =A0 CURVNET_RESTORE(); >> +#endif >> > > you don't really need =A0the #ifdef except for readability as CURVNET_XXX= ar > enot defined for !vnet > >> It's the type A) kind of change from above that will break eventually >> in the future. >> >> /bz >> > > --=20 //Monthadar Al Jaberi From owner-freebsd-virtualization@FreeBSD.ORG Wed Feb 2 19:06:17 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 D9334106564A; Wed, 2 Feb 2011 19:06:17 +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 AFFB88FC0C; Wed, 2 Feb 2011 19:06:17 +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 p12J6Ejf056601 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Feb 2011 11:06:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D49AB29.7070909@freebsd.org> Date: Wed, 02 Feb 2011 11:06:17 -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> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD virtualization mailing list 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 19:06:18 -0000 On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote: > I just tried something that seems to work, but please dont hit me ^^;;; > > in wtap_ioctl I assigned curthread->td_vnet myself to point to a VNET > (saved it when the module first loaded) (I have not created any jails > yet)... and it works... I didnt put any CURVNET macros... td->td_vnet is exactly what the CURVNET_SET macro sets. You should use the Macros because we may change the place where we store it. The vnet for the current thread is picked up from several places depending on the context, and it is cleared again when it is not needed. the V_xxx usages in the code end up being in effect expanded to curthread->td_vnet.xxx, where each 'xxx' is sort of like an element in a structure but not quite. Now, theoretically we could just leave it set all the time but then it would be nearly impossible to find places where we should have changed it, but forgot and just got the existing one. if you want to find the correct place to go, then look at the vnet of the calling process which should be in the process cred. or just use vnet0. I don't understand why you saw a CRED_TO_VNET of 0 I was under the impression that every process/thread in the system would be on vnet0 in a vimage kernel. your stored vnet idea is ok as well, but may go strange if you load the driver from a vnet jail and then remove the jail. > my assumption is that if ath drivers dont use VNET I shouldnt :P > > What is wrong with this hack? > > br, > > P.S. I have printed "porting to vnet" text to have it always at hand, > but its a bit hard for me... doing my best. > > On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer wrote: >> On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: >>> On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: >>> >>> Hi, >>> >>>> 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 >>> Try to load it from laoder on boot; I think that should work as we are >>> setting the curvent for the kernel startup. >>> >>> The problem you are seeing is a bug in the current implementation that >>> you cannot add any physical network interface after the kernel started. >>> This applies to cardbus/usb/... as well as any kind of ethernet >>> interface, so a kldload igb should yield it as well. >>> >>> The fix for that is easy and hard at the same time: >>> A) either touch all drivers >>> B) or touch all cloned interfaces and change 3 common lines. >>> or try to make cloners aware of vimages. >>> >>> Solution B) is sitting in perforce with the entire stuff that it depends >>> on and was started with CH=179022,179255 but not limited to that if you >>> want to have a peek. >>> >>> What you certainly can do locally to your driver for now is to make a >>> change like this: >>> >>> +#ifdef VIMAGE >>> + CURVNET_SET(vnet0); >>> +#endif >>> ifp = if_alloc(IFT_ETHER); >>> +#ifdef VIMAGE >>> + CURVNET_RESTORE(); >>> +#endif >>> >> you don't really need the #ifdef except for readability as CURVNET_XXX ar >> enot defined for !vnet >> >>> It's the type A) kind of change from above that will break eventually >>> in the future. >>> >>> /bz >>> >> > > From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 09:29:10 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 D546D106566B; Thu, 3 Feb 2011 09:29:10 +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 152358FC12; Thu, 3 Feb 2011 09:29:09 +0000 (UTC) Received: by wyf19 with SMTP id 19so934211wyf.13 for ; Thu, 03 Feb 2011 01:29:09 -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=qvr/oCU+JXXKfu7QdZ8LrJCv//mPIqSIdgChmj8tA+U=; b=cDMKMJyZ7OmJ2f7wBndbNnZWjfMRLbFcCZvxeCdv5VaiDbNTIB9i3TpqhnGrzZD7Ok U89AmIu+J3/XGdyRrrTQkyBEVPZ34c9W2i+Zi1e1SfNFI1U+7hMT1kRq23jFlnarcC7j F6i9RvkLae39yeNp9HxkPHnTuaSJvPf7t6mAo= 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=YiTmVcJiEJsgeYSTJ0hETDo9GapHMHS7BSdNT5UQ0ecFg2AyihgGIsNPxGkZg83jLK k9+7HwMZBpH1lh6BIH0b13sXtxgWGmNuCLP14AHxio5jMM/334oupZopITZWRgbvRXkG AxPzcuzEDHxyVI4tFRzNLZQptmOiZzB6pC7PE= MIME-Version: 1.0 Received: by 10.227.156.137 with SMTP id x9mr8799831wbw.108.1296725348606; Thu, 03 Feb 2011 01:29:08 -0800 (PST) Received: by 10.227.134.137 with HTTP; Thu, 3 Feb 2011 01:29:08 -0800 (PST) In-Reply-To: <4D49AB29.7070909@freebsd.org> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> Date: Thu, 3 Feb 2011 10:29:08 +0100 Message-ID: From: Monthadar Al Jaberi To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 09:29:10 -0000 On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer wrote: > On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote: >> >> I just tried something that seems to work, but please dont hit me ^^;;; >> >> in wtap_ioctl I assigned curthread->td_vnet myself to point to a VNET >> (saved it when the module first loaded) (I have not created any jails >> yet)... and it works... I didnt put any CURVNET macros... > > td->td_vnet is exactly what the CURVNET_SET macro sets. > You should use the Macros because we may change the place where we store = it. > > The vnet for the current thread is picked up from several places dependin= g > on the context, > and it is cleared again when it is not needed. =A0the V_xxx usages in the= code > end up being > in effect expanded to curthread->td_vnet.xxx, where each 'xxx' is sort of > like an element in a structure > but not quite. > > Now, theoretically we could just leave it set all the time but then it wo= uld > be nearly impossible > to find places where we should have changed it, but forgot and just got t= he > existing one. > > if you want to find the correct place to go, then look at the vnet of the > calling process > which should be in the process cred. or just use vnet0. Can I check it from user space? > > I don't understand why you saw a CRED_TO_VNET of 0 > I was under the impression that every process/thread in the system would = be > on vnet0 > in a vimage kernel. This is how my printf looks like: struct thread *td =3D curthread; struct vnet *v =3D TD_TO_VNET(td); struct ucred *cred =3D CRED_TO_VNET(td->ucred); struct vnet *td_vnet =3D td->td_vnet; printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p, CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); I made a fast search in /usr/src for "td_vnet" and found it was assigned only in int fork1(td, flags, pages, procp): #ifdef VIMAGE td2->td_vnet =3D NULL; td2->td_vnet_lpush =3D NULL; #endif Maybe something wrong with how I declare my wtap_ioctl: static struct cdevsw wtap_cdevsw =3D { .d_version =3D D_VERSION, .d_flags =3D 0, .d_ioctl =3D wtap_ioctl, .d_name =3D "wtapctl", }; ... make_dev(&wtap_cdevsw,0,UID_ROOT,GID_WHEEL,0600,(const char *)"wtapctl"); > > your stored vnet idea is ok as well, but may go strange if you load the > driver from a vnet jail > and then remove the jail. Ok, will document it in the code for now > > > > >> my assumption is that if ath drivers dont use VNET I shouldnt :P >> >> What is wrong with this hack? >> >> br, >> >> P.S. I have printed "porting to vnet" text to have it always at hand, >> but its a bit hard for me... doing my best. >> >> On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer >> =A0wrote: >>> >>> On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: >>>> >>>> On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: >>>> >>>> Hi, >>>> >>>>> Thanx makes more sense, but I have noticed something weired if you ca= n >>>>> 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 >>>> >>>> Try to load it from laoder on boot; I think that should work as we are >>>> setting the curvent for the kernel startup. >>>> >>>> The problem you are seeing is a bug in the current implementation that >>>> you cannot add any physical network interface after the kernel started= . >>>> This applies to cardbus/usb/... as well as any kind of ethernet >>>> interface, so a kldload igb should yield it as well. >>>> >>>> The fix for that is easy and hard at the same time: >>>> A) either touch all drivers >>>> B) or touch all cloned interfaces and change 3 common lines. >>>> =A0 or try to make cloners aware of vimages. >>>> >>>> Solution B) is sitting in perforce with the entire stuff that it depen= ds >>>> on and was started with CH=3D179022,179255 but not limited to that if = you >>>> want to have a peek. >>>> >>>> What you certainly can do locally to your driver for now is to make a >>>> change like this: >>>> >>>> +#ifdef VIMAGE >>>> + =A0 =A0 =A0 CURVNET_SET(vnet0); >>>> +#endif >>>> =A0 =A0 =A0 =A0ifp =3D if_alloc(IFT_ETHER); >>>> +#ifdef VIMAGE >>>> + =A0 =A0 =A0 CURVNET_RESTORE(); >>>> +#endif >>>> >>> you don't really need =A0the #ifdef except for readability as CURVNET_X= XX >>> ar >>> enot defined for !vnet >>> >>>> It's the type A) kind of change from above that will break eventually >>>> in the future. >>>> >>>> /bz >>>> >>> >> >> > > --=20 //Monthadar Al Jaberi From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 10:00:24 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 191ED1065679; Thu, 3 Feb 2011 10:00:24 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 082E98FC0A; Thu, 3 Feb 2011 10:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D0A6941C6A1; Thu, 3 Feb 2011 11:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id KR4SVUK8D0Ef; Thu, 3 Feb 2011 11:00:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 3864A41C6B4; Thu, 3 Feb 2011 11:00:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 884614448F3; Thu, 3 Feb 2011 09:55:16 +0000 (UTC) Date: Thu, 3 Feb 2011 09:55:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110203095019.N80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1502181884-1296726916=:80258" Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 10:00:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1502181884-1296726916=:80258 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer wrot= e: >> On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote: >>> >>> I just tried something that seems to work, but please dont hit me ^^;;; >>> >>> in wtap_ioctl I assigned curthread->td_vnet myself to point to a VNET >>> (saved it when the module first loaded) (I have not created any jails >>> yet)... and it works... I didnt put any CURVNET macros... >> >> td->td_vnet is exactly what the CURVNET_SET macro sets. >> You should use the Macros because we may change the place where we store= it. >> >> The vnet for the current thread is picked up from several places dependi= ng >> on the context, >> and it is cleared again when it is not needed. =A0the V_xxx usages in th= e code >> end up being >> in effect expanded to curthread->td_vnet.xxx, where each 'xxx' is sort o= f >> like an element in a structure >> but not quite. >> >> Now, theoretically we could just leave it set all the time but then it w= ould >> be nearly impossible >> to find places where we should have changed it, but forgot and just got = the >> existing one. >> >> if you want to find the correct place to go, then look at the vnet of th= e >> calling process >> which should be in the process cred. or just use vnet0. > > Can I check it from user space? > >> >> I don't understand why you saw a CRED_TO_VNET of 0 >> I was under the impression that every process/thread in the system would= be >> on vnet0 >> in a vimage kernel. > > This is how my printf looks like: > struct thread *td =3D curthread; > struct vnet *v =3D TD_TO_VNET(td); > struct ucred *cred =3D CRED_TO_VNET(td->ucred); > struct vnet *td_vnet =3D td->td_vnet; here's your problem: strcut vnet *vnet =3D cred->cr_prison->pr_vnet; > printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p, > CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); > > I made a fast search in /usr/src for "td_vnet" and found it was > assigned only in > int fork1(td, flags, pages, procp): > #ifdef VIMAGE > =09td2->td_vnet =3D NULL; > =09td2->td_vnet_lpush =3D NULL; > #endif Nice try. Want another search? Hint: there is this in vnet.h: #define curvnet curthread->td_vnet And then you'll, again, find the CURVNET_SET_* macros. > Maybe something wrong with how I declare my wtap_ioctl: > > static struct cdevsw wtap_cdevsw =3D { > =09.d_version =3D=09D_VERSION, > =09.d_flags =3D=090, > =09.d_ioctl =3D=09wtap_ioctl, > =09.d_name =3D=09"wtapctl", > }; > ... > make_dev(&wtap_cdevsw,0,UID_ROOT,GID_WHEEL,0600,(const char *)"wtapctl"); > >> >> your stored vnet idea is ok as well, but may go strange if you load the >> driver from a vnet jail >> and then remove the jail. > > Ok, will document it in the code for now > >> >> >> >> >>> my assumption is that if ath drivers dont use VNET I shouldnt :P >>> >>> What is wrong with this hack? >>> >>> br, >>> >>> P.S. I have printed "porting to vnet" text to have it always at hand, >>> but its a bit hard for me... doing my best. >>> >>> On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer >>> =A0wrote: >>>> >>>> On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: >>>>> >>>>> On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: >>>>> >>>>> Hi, >>>>> >>>>>> Thanx makes more sense, but I have noticed something weired if you c= an >>>>>> 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 >>>>> >>>>> Try to load it from laoder on boot; I think that should work as we ar= e >>>>> setting the curvent for the kernel startup. >>>>> >>>>> The problem you are seeing is a bug in the current implementation tha= t >>>>> you cannot add any physical network interface after the kernel starte= d. >>>>> This applies to cardbus/usb/... as well as any kind of ethernet >>>>> interface, so a kldload igb should yield it as well. >>>>> >>>>> The fix for that is easy and hard at the same time: >>>>> A) either touch all drivers >>>>> B) or touch all cloned interfaces and change 3 common lines. >>>>> =A0 or try to make cloners aware of vimages. >>>>> >>>>> Solution B) is sitting in perforce with the entire stuff that it depe= nds >>>>> on and was started with CH=3D179022,179255 but not limited to that if= you >>>>> want to have a peek. >>>>> >>>>> What you certainly can do locally to your driver for now is to make a >>>>> change like this: >>>>> >>>>> +#ifdef VIMAGE >>>>> + =A0 =A0 =A0 CURVNET_SET(vnet0); >>>>> +#endif >>>>> =A0 =A0 =A0 =A0ifp =3D if_alloc(IFT_ETHER); >>>>> +#ifdef VIMAGE >>>>> + =A0 =A0 =A0 CURVNET_RESTORE(); >>>>> +#endif >>>>> >>>> you don't really need =A0the #ifdef except for readability as CURVNET_= XXX >>>> ar >>>> enot defined for !vnet >>>> >>>>> It's the type A) kind of change from above that will break eventually >>>>> in the future. >>>>> >>>>> /bz >>>>> >>>> >>> >>> >> >> > > > > --=20 Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --0-1502181884-1296726916=:80258-- From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 10:51:25 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 108301065670; Thu, 3 Feb 2011 10:51:25 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9468FC0A; Thu, 3 Feb 2011 10:51:24 +0000 (UTC) Received: by wwf26 with SMTP id 26so974487wwf.31 for ; Thu, 03 Feb 2011 02:51:23 -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=DU2PNzljiAOOEJ8PbSIiHLerOR3EXyhQIs/OG2WQ3XE=; b=e1UjcChpR3usrVdXy0vyg2H5vHwvjUJk3DeJ71rhWOQ4AAxuiHelX7w+oMZacP48cA iQ6CGi4Q3sX41p9BvfMZHM41vQbDsp1hYJE91zlVWsOvfktmNpg+vCSjI9nD0JpMe+xF MLcGTHuIa7jKtqpc7Yo+n71uS+erHVXigk5t0= 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=lrUdrBiGn9W1NYVUTnMkaGqSGOaPoZ9JFBz+sxuu3d2UmqL9WMqKf+9B/0B87uPEKj 2CZlXxIi5OTktdI9BtVbXMlMvkMKhXGxNHZzKe7QU1AghSxlynM8DoO0YW3UA+t5Vzxu NIjwFr/cgmURcZng744GR5BBZAyK0AHeW5fXI= MIME-Version: 1.0 Received: by 10.227.143.11 with SMTP id s11mr10442002wbu.21.1296730283145; Thu, 03 Feb 2011 02:51:23 -0800 (PST) Received: by 10.227.134.137 with HTTP; Thu, 3 Feb 2011 02:51:23 -0800 (PST) In-Reply-To: <20110203095019.N80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> Date: Thu, 3 Feb 2011 11:51:23 +0100 Message-ID: From: Monthadar Al Jaberi To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 10:51:25 -0000 On Thu, Feb 3, 2011 at 10:55 AM, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > >> On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer >> wrote: >>> >>> On 2/2/11 10:05 AM, Monthadar Al Jaberi wrote: >>>> >>>> I just tried something that seems to work, but please dont hit me ^^;;= ; >>>> >>>> in wtap_ioctl I assigned curthread->td_vnet myself to point to a VNET >>>> (saved it when the module first loaded) (I have not created any jails >>>> yet)... and it works... I didnt put any CURVNET macros... >>> >>> td->td_vnet is exactly what the CURVNET_SET macro sets. >>> You should use the Macros because we may change the place where we stor= e >>> it. >>> >>> The vnet for the current thread is picked up from several places >>> depending >>> on the context, >>> and it is cleared again when it is not needed. =A0the V_xxx usages in t= he >>> code >>> end up being >>> in effect expanded to curthread->td_vnet.xxx, where each 'xxx' is sort = of >>> like an element in a structure >>> but not quite. >>> >>> Now, theoretically we could just leave it set all the time but then it >>> would >>> be nearly impossible >>> to find places where we should have changed it, but forgot and just got >>> the >>> existing one. >>> >>> if you want to find the correct place to go, then look at the vnet of t= he >>> calling process >>> which should be in the process cred. or just use vnet0. >> >> Can I check it from user space? >> >>> >>> I don't understand why you saw a CRED_TO_VNET of 0 >>> I was under the impression that every process/thread in the system woul= d >>> be >>> on vnet0 >>> in a vimage kernel. >> >> This is how my printf looks like: >> struct thread *td =3D curthread; >> struct vnet *v =3D TD_TO_VNET(td); >> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >> struct vnet *td_vnet =3D td->td_vnet; > > here's your problem: > > strcut vnet *vnet =3D cred->cr_prison->pr_vnet; When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a panic to= o... But your suggestion works if I do like this: curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; CRED_TO_VNET(curthread->td_ucred) returns NULL > > >> printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p, >> CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); >> >> I made a fast search in /usr/src for "td_vnet" and found it was >> assigned only in >> int fork1(td, flags, pages, procp): >> #ifdef VIMAGE >> =A0 =A0 =A0 =A0td2->td_vnet =3D NULL; >> =A0 =A0 =A0 =A0td2->td_vnet_lpush =3D NULL; >> #endif > > Nice try. =A0Want another search? =A0Hint: there is this in vnet.h: > > #define curvnet curthread->td_vnet > > And then you'll, again, find the CURVNET_SET_* macros. Thank you > > > >> Maybe something wrong with how I declare my wtap_ioctl: >> >> static struct cdevsw wtap_cdevsw =3D { >> =A0 =A0 =A0 =A0.d_version =3D =A0 =A0D_VERSION, >> =A0 =A0 =A0 =A0.d_flags =3D =A0 =A0 =A00, >> =A0 =A0 =A0 =A0.d_ioctl =3D =A0 =A0 =A0wtap_ioctl, >> =A0 =A0 =A0 =A0.d_name =3D =A0 =A0 =A0 "wtapctl", >> }; >> ... >> make_dev(&wtap_cdevsw,0,UID_ROOT,GID_WHEEL,0600,(const char *)"wtapctl")= ; >> >>> >>> your stored vnet idea is ok as well, but may go strange if you load the >>> driver from a vnet jail >>> and then remove the jail. >> >> Ok, will document it in the code for now >> >>> >>> >>> >>> >>>> my assumption is that if ath drivers dont use VNET I shouldnt :P >>>> >>>> What is wrong with this hack? >>>> >>>> br, >>>> >>>> P.S. I have printed "porting to vnet" text to have it always at hand, >>>> but its a bit hard for me... doing my best. >>>> >>>> On Wed, Feb 2, 2011 at 6:30 PM, Julian Elischer >>>> =A0wrote: >>>>> >>>>> On 2/2/11 9:12 AM, Bjoern A. Zeeb wrote: >>>>>> >>>>>> On Wed, 2 Feb 2011, Monthadar Al Jaberi wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>>> 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 >>>>>> >>>>>> Try to load it from laoder on boot; I think that should work as we a= re >>>>>> setting the curvent for the kernel startup. >>>>>> >>>>>> The problem you are seeing is a bug in the current implementation th= at >>>>>> you cannot add any physical network interface after the kernel >>>>>> started. >>>>>> This applies to cardbus/usb/... as well as any kind of ethernet >>>>>> interface, so a kldload igb should yield it as well. >>>>>> >>>>>> The fix for that is easy and hard at the same time: >>>>>> A) either touch all drivers >>>>>> B) or touch all cloned interfaces and change 3 common lines. >>>>>> =A0 or try to make cloners aware of vimages. >>>>>> >>>>>> Solution B) is sitting in perforce with the entire stuff that it >>>>>> depends >>>>>> on and was started with CH=3D179022,179255 but not limited to that i= f >>>>>> you >>>>>> want to have a peek. >>>>>> >>>>>> What you certainly can do locally to your driver for now is to make = a >>>>>> change like this: >>>>>> >>>>>> +#ifdef VIMAGE >>>>>> + =A0 =A0 =A0 CURVNET_SET(vnet0); >>>>>> +#endif >>>>>> =A0 =A0 =A0 =A0ifp =3D if_alloc(IFT_ETHER); >>>>>> +#ifdef VIMAGE >>>>>> + =A0 =A0 =A0 CURVNET_RESTORE(); >>>>>> +#endif >>>>>> >>>>> you don't really need =A0the #ifdef except for readability as CURVNET= _XXX >>>>> ar >>>>> enot defined for !vnet >>>>> >>>>>> It's the type A) kind of change from above that will break eventuall= y >>>>>> in the future. >>>>>> >>>>>> /bz >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >> >> > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 You have to have visions! > =A0 =A0 =A0 =A0 Going to jail sucks -- All my daemons like it! > =A0http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --=20 //Monthadar Al Jaberi From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 11:00:07 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 297B0106566B for ; Thu, 3 Feb 2011 11:00:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id B80388FC14 for ; Thu, 3 Feb 2011 11:00:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 212C841C6A1; Thu, 3 Feb 2011 12:00:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qWatn7KruIj9; Thu, 3 Feb 2011 12:00:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 808A341C6B4; Thu, 3 Feb 2011 12:00:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 636334448F3; Thu, 3 Feb 2011 10:59:32 +0000 (UTC) Date: Thu, 3 Feb 2011 10:59:32 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110203105747.K80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-100765273-1296730772=:80258" Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 11:00:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-100765273-1296730772=:80258 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>> I was under the impression that every process/thread in the system wou= ld >>>> be >>>> on vnet0 >>>> in a vimage kernel. >>> >>> This is how my printf looks like: >>> struct thread *td =3D curthread; >>> struct vnet *v =3D TD_TO_VNET(td); >>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>> struct vnet *td_vnet =3D td->td_vnet; >> >> here's your problem: >> >> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; > > When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a panic = too... > But your suggestion works if I do like this: > curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; > > CRED_TO_VNET(curthread->td_ucred) returns NULL I wonder how you are building your module and if VIMAGE is properly defined. If it's not that would explain a lot of things. >>> printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p, >>> CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); >>> >>> I made a fast search in /usr/src for "td_vnet" and found it was >>> assigned only in >>> int fork1(td, flags, pages, procp): >>> #ifdef VIMAGE >>> =A0 =A0 =A0 =A0td2->td_vnet =3D NULL; >>> =A0 =A0 =A0 =A0td2->td_vnet_lpush =3D NULL; >>> #endif >> >> Nice try. =A0Want another search? =A0Hint: there is this in vnet.h: >> >> #define curvnet curthread->td_vnet >> >> And then you'll, again, find the CURVNET_SET_* macros. > > Thank you Something you may find useful as well btw is: http://people.freebsd.org/~bz/20100530-02.vnet.9.html --=20 Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --0-100765273-1296730772=:80258-- From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 11:06:47 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 9A403106564A for ; Thu, 3 Feb 2011 11:06:47 +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 2382D8FC08 for ; Thu, 3 Feb 2011 11:06:46 +0000 (UTC) Received: by wyf19 with SMTP id 19so1010370wyf.13 for ; Thu, 03 Feb 2011 03:06:46 -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=olUTCzIRbzePULxNSVrBYZBiaTPF4uIlXhtzCK7/kW0=; b=gqjGApmMhFRlPpR5p3ezokvUDbUhe/w0NTtfQoFrsEW71r7vtXFPwbLumLKt8pXWaZ qS0WddvbfETIDmP1r1CEEoZBNn3/kX3lf/7kKYqwBFCNcmBCz0orOd7kKidt3p3a/fKf o3sIzI6ob45XywdxopZUKsQxBbkdq92kAG52k= 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=ArmZ/fIfXU/2T2R5MRbCFVsMM6I4g4PSt2KFirq8D4dxhyV7rB3H11mIFRfpZUZq8G AKj2QqVMV27hbi42rNjHm1sGIBvSFW6zLak9FLkF3ddpDqwyGPaPRiBfrIzoSYhI58Jw 4Nt4iJ/q/W2S7DP9FzPoTLZHqzMjAylEiDMH0= MIME-Version: 1.0 Received: by 10.227.167.8 with SMTP id o8mr10379183wby.166.1296731205965; Thu, 03 Feb 2011 03:06:45 -0800 (PST) Received: by 10.227.134.137 with HTTP; Thu, 3 Feb 2011 03:06:45 -0800 (PST) In-Reply-To: <20110203105747.K80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> Date: Thu, 3 Feb 2011 12:06:45 +0100 Message-ID: From: Monthadar Al Jaberi To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 11:06:47 -0000 On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > >>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>> I was under the impression that every process/thread in the system >>>>> would >>>>> be >>>>> on vnet0 >>>>> in a vimage kernel. >>>> >>>> This is how my printf looks like: >>>> struct thread *td =3D curthread; >>>> struct vnet *v =3D TD_TO_VNET(td); >>>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>>> struct vnet *td_vnet =3D td->td_vnet; >>> >>> here's your problem: >>> >>> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; >> >> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a panic >> too... >> But your suggestion works if I do like this: >> curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; >> >> CRED_TO_VNET(curthread->td_ucred) returns NULL > > I wonder how you are building your module and if VIMAGE is properly > defined. =A0If it's not that would explain a lot of things. I have put options VIMAGE, rebuild both world and kernel. I can create jails with vnet options... I build my module with the standard Makefile for modules: ... KMOD =3D wtap ... SRCS =3D if_wtap_module.c if_wtap.c if_medium.c hal.c .include > > >>>> printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p, >>>> CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); >>>> >>>> I made a fast search in /usr/src for "td_vnet" and found it was >>>> assigned only in >>>> int fork1(td, flags, pages, procp): >>>> #ifdef VIMAGE >>>> =A0 =A0 =A0 =A0td2->td_vnet =3D NULL; >>>> =A0 =A0 =A0 =A0td2->td_vnet_lpush =3D NULL; >>>> #endif >>> >>> Nice try. =A0Want another search? =A0Hint: there is this in vnet.h: >>> >>> #define curvnet curthread->td_vnet >>> >>> And then you'll, again, find the CURVNET_SET_* macros. >> >> Thank you > > Something you may find useful as well btw is: > > http://people.freebsd.org/~bz/20100530-02.vnet.9.html weired compiler complains about that there is no , I include maybe old documentation? > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 You have to have visions! > =A0 =A0 =A0 =A0 Going to jail sucks -- All my daemons like it! > =A0http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --=20 //Monthadar Al Jaberi From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 11:20:08 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 031EE1065673 for ; Thu, 3 Feb 2011 11:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 89BB88FC16 for ; Thu, 3 Feb 2011 11:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BEB1541C7A5; Thu, 3 Feb 2011 12:20:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id doskVVNEYUl8; Thu, 3 Feb 2011 12:20:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id D736C41C707; Thu, 3 Feb 2011 12:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CC1FC4448F3; Thu, 3 Feb 2011 11:18:36 +0000 (UTC) Date: Thu, 3 Feb 2011 11:18:36 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110203111206.S80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-689080525-1296731916=:80258" Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 11:20:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-689080525-1296731916=:80258 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb > wrote: >> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >> >>>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>>> I was under the impression that every process/thread in the system >>>>>> would >>>>>> be >>>>>> on vnet0 >>>>>> in a vimage kernel. >>>>> >>>>> This is how my printf looks like: >>>>> struct thread *td =3D curthread; >>>>> struct vnet *v =3D TD_TO_VNET(td); >>>>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>>>> struct vnet *td_vnet =3D td->td_vnet; >>>> >>>> here's your problem: >>>> >>>> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; >>> >>> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a pani= c >>> too... >>> But your suggestion works if I do like this: >>> curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; >>> >>> CRED_TO_VNET(curthread->td_ucred) returns NULL >> >> I wonder how you are building your module and if VIMAGE is properly >> defined. =A0If it's not that would explain a lot of things. > > I have put options VIMAGE, rebuild both world and kernel. > > I can create jails with vnet options... > > I build my module with the standard Makefile for modules: > ... > KMOD =3D wtap > ... > SRCS =3D if_wtap_module.c if_wtap.c if_medium.c hal.c > > .include Right but are you building your module along with the kernel or outside the tree? In the latter case you may want to add soemthing like SRCS+=3D opt_global.h =2Eif defined(KERNBUILDDIR) MKDEP=3D -include ${KERNBUILDDIR}/opt_global.h =2Eelse CFLAGS+=3D -include opt_global.h MKDEP=3D -include opt_global.h opt_global.h: echo "#define VIMAGE 1" > ${.TARGET} =2Eendif and/or point KERNBUILDDIR to where you built your kernels. >> >> >>>>> printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%p= , >>>>> CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); >>>>> >>>>> I made a fast search in /usr/src for "td_vnet" and found it was >>>>> assigned only in >>>>> int fork1(td, flags, pages, procp): >>>>> #ifdef VIMAGE >>>>> =A0 =A0 =A0 =A0td2->td_vnet =3D NULL; >>>>> =A0 =A0 =A0 =A0td2->td_vnet_lpush =3D NULL; >>>>> #endif >>>> >>>> Nice try. =A0Want another search? =A0Hint: there is this in vnet.h: >>>> >>>> #define curvnet curthread->td_vnet >>>> >>>> And then you'll, again, find the CURVNET_SET_* macros. >>> >>> Thank you >> >> Something you may find useful as well btw is: >> >> http://people.freebsd.org/~bz/20100530-02.vnet.9.html > > weired compiler complains about that there is no , I > include maybe old documentation? it's net/vnet.h. Documentation bug from a local transisiton time to the general framework. Thanks for catching;) net/vnet.h will obviously stay. --=20 Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --0-689080525-1296731916=:80258-- From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 12:07:23 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 41D82106566B for ; Thu, 3 Feb 2011 12:07:23 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BF8B88FC19 for ; Thu, 3 Feb 2011 12:07:20 +0000 (UTC) Received: by wwf26 with SMTP id 26so1039453wwf.31 for ; Thu, 03 Feb 2011 04:07:20 -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=Lw+hkzkjMFw3WtPGeLrA3yu7Su5IN5p8G/DUCsa7O1M=; b=TRJmr9FL7Llt/+0Yy1S4Q8FoaR3u9vfSNDC21cQewp30cgRBLYZ9TvTOWx/Svxoobz zoWwF72ECUcxVYJ4iYJrhzjhq9Se6vMjdv4h8kYScRXm6wr9tsMb97knrHk82XN8Ft+6 p9GDxcR6lWG8uEiO1Ar+tEQJoMx170tzZRNCc= 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=ZftEga3lzeEiqLtEUilSi+tJ90F+MZ8hsVJFZJ2WnWhvoZ8GYWXAB4sKNF6HnYLZQY o0HKAB7lJ8FYUpYR1mgJswUsWIJAzRCKsrKarvAc3/6oHjISxpR4Rki7aRpu0D6Xevkr idriK3uJ9w8Fc1c1p2tqlTsuNU4bNxxk250+U= MIME-Version: 1.0 Received: by 10.227.129.17 with SMTP id m17mr10504662wbs.79.1296734839486; Thu, 03 Feb 2011 04:07:19 -0800 (PST) Received: by 10.227.134.137 with HTTP; Thu, 3 Feb 2011 04:07:19 -0800 (PST) In-Reply-To: <20110203111206.S80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> <20110203111206.S80258@maildrop.int.zabbadoz.net> Date: Thu, 3 Feb 2011 13:07:19 +0100 Message-ID: From: Monthadar Al Jaberi To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 12:07:23 -0000 On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > >> On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb >> wrote: >>> >>> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >>> >>>>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>>>> I was under the impression that every process/thread in the system >>>>>>> would >>>>>>> be >>>>>>> on vnet0 >>>>>>> in a vimage kernel. >>>>>> >>>>>> This is how my printf looks like: >>>>>> struct thread *td =3D curthread; >>>>>> struct vnet *v =3D TD_TO_VNET(td); >>>>>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>>>>> struct vnet *td_vnet =3D td->td_vnet; >>>>> >>>>> here's your problem: >>>>> >>>>> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; >>>> >>>> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a pan= ic >>>> too... >>>> But your suggestion works if I do like this: >>>> curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; >>>> >>>> CRED_TO_VNET(curthread->td_ucred) returns NULL >>> >>> I wonder how you are building your module and if VIMAGE is properly >>> defined. =A0If it's not that would explain a lot of things. >> >> I have put options VIMAGE, rebuild both world and kernel. >> >> I can create jails with vnet options... >> >> I build my module with the standard Makefile for modules: >> ... >> KMOD =A0 =A0=3D =A0wtap >> ... >> SRCS =A0 =A0=3D =A0if_wtap_module.c if_wtap.c if_medium.c hal.c >> >> .include > > Right but are you building your module along with the kernel or > outside the tree? =A0In the latter case you may want to add soemthing > like > > SRCS+=3D =A0 =A0 =A0 =A0 =A0opt_global.h > > .if defined(KERNBUILDDIR) > MKDEP=3D =A0 =A0 =A0 =A0 =A0-include ${KERNBUILDDIR}/opt_global.h > .else > CFLAGS+=3D =A0 =A0 =A0 =A0-include opt_global.h > MKDEP=3D =A0 =A0 =A0 =A0 =A0-include opt_global.h > > opt_global.h: > =A0 =A0 =A0 =A0echo "#define VIMAGE 1" > ${.TARGET} > .endif > > and/or point KERNBUILDDIR to where you built your kernels. Thanks it works now.. > > >>> >>> >>>>>> printf("td=3D%p, td->td_vnet=3D%p, td->td_ucred=3D%p, TD_TO_VNET=3D%= p, >>>>>> CRED_TO_VNET=3D%p\n", td, td_vnet, td->td_ucred, v, cred); >>>>>> >>>>>> I made a fast search in /usr/src for "td_vnet" and found it was >>>>>> assigned only in >>>>>> int fork1(td, flags, pages, procp): >>>>>> #ifdef VIMAGE >>>>>> =A0 =A0 =A0 =A0td2->td_vnet =3D NULL; >>>>>> =A0 =A0 =A0 =A0td2->td_vnet_lpush =3D NULL; >>>>>> #endif >>>>> >>>>> Nice try. =A0Want another search? =A0Hint: there is this in vnet.h: >>>>> >>>>> #define curvnet curthread->td_vnet >>>>> >>>>> And then you'll, again, find the CURVNET_SET_* macros. >>>> >>>> Thank you >>> >>> Something you may find useful as well btw is: >>> >>> http://people.freebsd.org/~bz/20100530-02.vnet.9.html >> >> weired compiler complains about that there is no , I >> include maybe old documentation? > > it's net/vnet.h. =A0Documentation bug from a local transisiton time to > the general framework. =A0Thanks for catching;) =A0net/vnet.h will > obviously stay. > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 You have to have visions! > =A0 =A0 =A0 =A0 Going to jail sucks -- All my daemons like it! > =A0http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --=20 //Monthadar Al Jaberi From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 17:11:51 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 CA617106566C for ; Thu, 3 Feb 2011 17:11:51 +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 99B0D8FC1A for ; Thu, 3 Feb 2011 17:11:51 +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 p13HBm0D061367 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 09:11:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4AE1D7.9030106@freebsd.org> Date: Thu, 03 Feb 2011 09:11:51 -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: "Bjoern A. Zeeb" References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110203105747.K80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 17:11:51 -0000 On 2/3/11 2:59 AM, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > >>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>> I was under the impression that every process/thread in the >>>>> system would >>>>> be >>>>> on vnet0 >>>>> in a vimage kernel. >>>> >>>> This is how my printf looks like: >>>> struct thread *td = curthread; >>>> struct vnet *v = TD_TO_VNET(td); >>>> struct ucred *cred = CRED_TO_VNET(td->ucred); >>>> struct vnet *td_vnet = td->td_vnet; >>> >>> here's your problem: >>> >>> strcut vnet *vnet = cred->cr_prison->pr_vnet; >> >> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a >> panic too... >> But your suggestion works if I do like this: >> curthread->td_vnet = curthread->td_ucred->cr_prison->pr_vnet; >> >> CRED_TO_VNET(curthread->td_ucred) returns NULL > > I wonder how you are building your module and if VIMAGE is properly > defined. If it's not that would explain a lot of things. > > >>>> printf("td=%p, td->td_vnet=%p, td->td_ucred=%p, TD_TO_VNET=%p, >>>> CRED_TO_VNET=%p\n", td, td_vnet, td->td_ucred, v, cred); >>>> >>>> I made a fast search in /usr/src for "td_vnet" and found it was >>>> assigned only in >>>> int fork1(td, flags, pages, procp): >>>> #ifdef VIMAGE >>>> td2->td_vnet = NULL; >>>> td2->td_vnet_lpush = NULL; >>>> #endif >>> >>> Nice try. Want another search? Hint: there is this in vnet.h: >>> >>> #define curvnet curthread->td_vnet >>> >>> And then you'll, again, find the CURVNET_SET_* macros. >> >> Thank you > > Something you may find useful as well btw is: > > http://people.freebsd.org/~bz/20100530-02.vnet.9.html that's excellent! checkin? > > > _______________________________________________ > 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" From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 19:35:11 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 9E1D91065708 for ; Thu, 3 Feb 2011 19:35:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 205148FC08 for ; Thu, 3 Feb 2011 19:35:11 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 85BE141C757; Thu, 3 Feb 2011 20:35:09 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 3XnYwgiCd+Zb; Thu, 3 Feb 2011 20:35:09 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 1E64041C6DB; Thu, 3 Feb 2011 20:35:09 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 705BA4448F3; Thu, 3 Feb 2011 19:35:03 +0000 (UTC) Date: Thu, 3 Feb 2011 19:35:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Monthadar Al Jaberi In-Reply-To: Message-ID: <20110203193259.L80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> <20110203111206.S80258@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1541120788-1296761703=:80258" Cc: FreeBSD virtualization mailing list 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: Thu, 03 Feb 2011 19:35:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1541120788-1296761703=:80258 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb > wrote: >> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >> >>> On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb >>> wrote: >>>> >>>> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >>>> >>>>>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>>>>> I was under the impression that every process/thread in the system >>>>>>>> would >>>>>>>> be >>>>>>>> on vnet0 >>>>>>>> in a vimage kernel. >>>>>>> >>>>>>> This is how my printf looks like: >>>>>>> struct thread *td =3D curthread; >>>>>>> struct vnet *v =3D TD_TO_VNET(td); >>>>>>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>>>>>> struct vnet *td_vnet =3D td->td_vnet; >>>>>> >>>>>> here's your problem: >>>>>> >>>>>> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; >>>>> >>>>> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a pa= nic >>>>> too... >>>>> But your suggestion works if I do like this: >>>>> curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; >>>>> >>>>> CRED_TO_VNET(curthread->td_ucred) returns NULL >>>> >>>> I wonder how you are building your module and if VIMAGE is properly >>>> defined. =A0If it's not that would explain a lot of things. >>> >>> I have put options VIMAGE, rebuild both world and kernel. >>> >>> I can create jails with vnet options... >>> >>> I build my module with the standard Makefile for modules: >>> ... >>> KMOD =A0 =A0=3D =A0wtap >>> ... >>> SRCS =A0 =A0=3D =A0if_wtap_module.c if_wtap.c if_medium.c hal.c >>> >>> .include >> >> Right but are you building your module along with the kernel or >> outside the tree? =A0In the latter case you may want to add soemthing >> like >> >> SRCS+=3D =A0 =A0 =A0 =A0 =A0opt_global.h >> >> .if defined(KERNBUILDDIR) >> MKDEP=3D =A0 =A0 =A0 =A0 =A0-include ${KERNBUILDDIR}/opt_global.h >> .else >> CFLAGS+=3D =A0 =A0 =A0 =A0-include opt_global.h >> MKDEP=3D =A0 =A0 =A0 =A0 =A0-include opt_global.h >> >> opt_global.h: >> =A0 =A0 =A0 =A0echo "#define VIMAGE 1" > ${.TARGET} >> .endif >> >> and/or point KERNBUILDDIR to where you built your kernels. > > Thanks it works now.. One thing you should be aware of is that if you will compile without KERNBUILDDIR set, your module will not work on a non-VIMAGE kernel. Unfortuantely we can only have defaults for one or the other in the case. Worst you may want to only do the "echo" if there was a command line option like -DVIMAGE or the like. Note, setting it to 0 will not do the trick as it would still be defined. /bz --=20 Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html --0-1541120788-1296761703=:80258-- From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 19:50:07 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 5A551106566B for ; Thu, 3 Feb 2011 19:50:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 104388FC1A for ; Thu, 3 Feb 2011 19:50:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6A36241C7A6 for ; Thu, 3 Feb 2011 20:50:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id DMWIWa3+Agg1 for ; Thu, 3 Feb 2011 20:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 989E041C7AB; Thu, 3 Feb 2011 20:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2165B4448F3 for ; Thu, 3 Feb 2011 19:47:30 +0000 (UTC) Date: Thu, 3 Feb 2011 19:47:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD virtualization mailing list Message-ID: <20110203193535.X80258@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: HEADS UP: tenetative plan to merge VIMAGE parts 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: Thu, 03 Feb 2011 19:50:07 -0000 Hi, I will be at FOSDEM this weekend (if you are as well and want to talk, send me an email off list or try to find me in the crowds). When back next week I plan to extract the initial parts from perforce and merge them to SVN. This will include: 1) vnet socket pushdown. followed by: 2) general VIMAGE framework. and 3) user space changes. probably along with some "noise" to ddb and documentation. it could be that VIMAGE in HEAD would be "unstable" for a couple of days during these times. This batch will not yet include actual VNET teardwn or interface cloners changes but will provide the foundation for that. I hope I'll be able to quickly afterwards make the patches for the interface cloners available and in addition to the bridge code posted and the carp code I have, so we can look at the missing cloned interfaces state, while in parallel trying to get ports breakage figured out. I'll keep you updated during next week as things progress and might post merge candidate patches for your testing. Regards, Bjoern -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-virtualization@FreeBSD.ORG Thu Feb 3 22:37:46 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 CBFB4106566B; Thu, 3 Feb 2011 22:37:46 +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 9ED4E8FC16; Thu, 3 Feb 2011 22:37:46 +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 p13MbfgB062322 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 14:37:45 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4D4B2E37.8050604@freebsd.org> Date: Thu, 03 Feb 2011 14:37:43 -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: "Bjoern A. Zeeb" References: <20110203193535.X80258@maildrop.int.zabbadoz.net> In-Reply-To: <20110203193535.X80258@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD virtualization mailing list Subject: Re: HEADS UP: tenetative plan to merge VIMAGE parts 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: Thu, 03 Feb 2011 22:37:46 -0000 On 2/3/11 11:47 AM, Bjoern A. Zeeb wrote: > Hi, > > I will be at FOSDEM this weekend (if you are as well and want to talk, > send me an email off list or try to find me in the crowds). When back > next week I plan to extract the initial parts from perforce and merge > them to SVN. This will include: > > 1) vnet socket pushdown. > > followed by: > 2) general VIMAGE framework. > > and > 3) user space changes. > > probably along with some "noise" to ddb and documentation. it could > be that VIMAGE in HEAD would be "unstable" for a couple of days during > these times. > the sooner the better I think > > This batch will not yet include actual VNET teardwn or interface > cloners changes but will provide the foundation for that. > > I hope I'll be able to quickly afterwards make the patches for the > interface > cloners available and in addition to the bridge code posted and the > carp > code I have, so we can look at the missing cloned interfaces state, > while > in parallel trying to get ports breakage figured out. > > I'll keep you updated during next week as things progress and might > post merge candidate patches for your testing. > > Regards, > Bjoern > From owner-freebsd-virtualization@FreeBSD.ORG Fri Feb 4 07:16:12 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 D0B5810656A6 for ; Fri, 4 Feb 2011 07:16:12 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5F68FC12 for ; Fri, 4 Feb 2011 07:16:12 +0000 (UTC) Received: by gyf3 with SMTP id 3so849956gyf.13 for ; Thu, 03 Feb 2011 23:16:11 -0800 (PST) Received: by 10.236.110.172 with SMTP id u32mr23428828yhg.63.1296802049581; Thu, 03 Feb 2011 22:47:29 -0800 (PST) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.236.105.230 with HTTP; Thu, 3 Feb 2011 22:47:09 -0800 (PST) In-Reply-To: <20110203193259.L80258@maildrop.int.zabbadoz.net> References: <4D484213.6050100@freebsd.org> <4D486108.5060805@freebsd.org> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <4D49AB29.7070909@freebsd.org> <20110203095019.N80258@maildrop.int.zabbadoz.net> <20110203105747.K80258@maildrop.int.zabbadoz.net> <20110203111206.S80258@maildrop.int.zabbadoz.net> <20110203193259.L80258@maildrop.int.zabbadoz.net> From: Adrian Penisoara Date: Fri, 4 Feb 2011 08:47:09 +0200 X-Google-Sender-Auth: 8uDIe6dFN1v7cg92O_MiQYSE8bI Message-ID: To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD virtualization mailing list 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: Fri, 04 Feb 2011 07:16:12 -0000 Hi, Since we're going to see VIMAGE (partly) committed into HEAD anytime now, perhaps it would be a good time to make available some clear developer documentation on how to cope with VIMAGE in the kernel (at kernel build time or building a module separately). 3rd party driver vendors will be most interested in this. PS: it would be very welcoming for such mechanisms to be elegant in their usage ;)... Thank you, Adrian. On Thu, Feb 3, 2011 at 9:35 PM, Bjoern A. Zeeb wrote: > On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: > >> On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb >> wrote: >>> >>> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >>> >>>> On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb >>>> wrote: >>>>> >>>>> On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote: >>>>> >>>>>>>>> I don't understand why you saw a CRED_TO_VNET of 0 >>>>>>>>> I was under the impression that every process/thread in the syste= m >>>>>>>>> would >>>>>>>>> be >>>>>>>>> on vnet0 >>>>>>>>> in a vimage kernel. >>>>>>>> >>>>>>>> This is how my printf looks like: >>>>>>>> struct thread *td =3D curthread; >>>>>>>> struct vnet *v =3D TD_TO_VNET(td); >>>>>>>> struct ucred *cred =3D CRED_TO_VNET(td->ucred); >>>>>>>> struct vnet *td_vnet =3D td->td_vnet; >>>>>>> >>>>>>> here's your problem: >>>>>>> >>>>>>> strcut vnet *vnet =3D cred->cr_prison->pr_vnet; >>>>>> >>>>>> When I add CURVNET_SET(CRED_TO_VNET(curthread->td_ucred)); I get a >>>>>> panic >>>>>> too... >>>>>> But your suggestion works if I do like this: >>>>>> curthread->td_vnet =3D curthread->td_ucred->cr_prison->pr_vnet; >>>>>> >>>>>> CRED_TO_VNET(curthread->td_ucred) returns NULL >>>>> >>>>> I wonder how you are building your module and if VIMAGE is properly >>>>> defined. =A0If it's not that would explain a lot of things. >>>> >>>> I have put options VIMAGE, rebuild both world and kernel. >>>> >>>> I can create jails with vnet options... >>>> >>>> I build my module with the standard Makefile for modules: >>>> ... >>>> KMOD =A0 =A0=3D =A0wtap >>>> ... >>>> SRCS =A0 =A0=3D =A0if_wtap_module.c if_wtap.c if_medium.c hal.c >>>> >>>> .include >>> >>> Right but are you building your module along with the kernel or >>> outside the tree? =A0In the latter case you may want to add soemthing >>> like >>> >>> SRCS+=3D =A0 =A0 =A0 =A0 =A0opt_global.h >>> >>> .if defined(KERNBUILDDIR) >>> MKDEP=3D =A0 =A0 =A0 =A0 =A0-include ${KERNBUILDDIR}/opt_global.h >>> .else >>> CFLAGS+=3D =A0 =A0 =A0 =A0-include opt_global.h >>> MKDEP=3D =A0 =A0 =A0 =A0 =A0-include opt_global.h >>> >>> opt_global.h: >>> =A0 =A0 =A0 =A0echo "#define VIMAGE 1" > ${.TARGET} >>> .endif >>> >>> and/or point KERNBUILDDIR to where you built your kernels. >> >> Thanks it works now.. > > > One thing you should be aware of is that if you will compile without > KERNBUILDDIR set, your module will not work on a non-VIMAGE kernel. > > Unfortuantely we can only have defaults for one or the other in the > case. =A0Worst you may want to only do the "echo" if there was a command > line option like -DVIMAGE or the like. =A0Note, setting it to 0 will not > do the trick as it would still be defined. > > /bz > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 You have to have visions! > =A0 =A0 =A0 =A0 Going to jail sucks -- All my daemons like it! > =A0http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > _______________________________________________ > 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" > >