Date: Tue, 01 Feb 2011 09:25:39 -0800 From: Julian Elischer <julian@freebsd.org> To: Monthadar Al Jaberi <monthadar@gmail.com> Cc: freebsd-virtualization@freebsd.org Subject: Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE) Message-ID: <4D484213.6050100@freebsd.org> In-Reply-To: <AANLkTik8D_bLwcUKZdBT-kpkJdDXtPTLvAqfUe0cLoSz@mail.gmail.com> References: <AANLkTik8D_bLwcUKZdBT-kpkJdDXtPTLvAqfUe0cLoSz@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D484213.6050100>