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