Date: Thu, 3 Feb 2011 10:29:08 +0100 From: Monthadar Al Jaberi <monthadar@gmail.com> To: Julian Elischer <julian@freebsd.org> Cc: "Bjoern A. Zeeb" <bz@freebsd.org>, FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org> Subject: Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE) Message-ID: <AANLkTinONnLE9D=c57nQmGBFbWJgqJmeKiRViW3gga2a@mail.gmail.com> In-Reply-To: <4D49AB29.7070909@freebsd.org> References: <AANLkTik8D_bLwcUKZdBT-kpkJdDXtPTLvAqfUe0cLoSz@mail.gmail.com> <4D484213.6050100@freebsd.org> <AANLkTikJKZLQVA5X2PQs0oT4iFsZYBw7K07kjQTc9iGD@mail.gmail.com> <4D486108.5060805@freebsd.org> <AANLkTi=mk2vfyXJBaK5mV2sBWEj0-RDZneLs%2BXq_c7sb@mail.gmail.com> <20110202164827.I80258@maildrop.int.zabbadoz.net> <4D4994CE.2090209@freebsd.org> <AANLkTimDZRefv57_nanxGUbHjP1wqeQ41iWHvpXogmvU@mail.gmail.com> <4D49AB29.7070909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer <julian@freebsd.org> 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<julian@freebsd.org>
>> =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinONnLE9D=c57nQmGBFbWJgqJmeKiRViW3gga2a>