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--