Re: VirtualBox + VIMAGE
On Wed, 2 Mar 2011 15:09:21 -0600, Brandon Gooch wrote: On Wed, Mar 2, 2011 at 2:52 PM, Bernhard Froehlich de...@bluelife.at wrote: On Wed, 02 Mar 2011 21:31:45 +0100, Bernhard Froehlich wrote: On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) It looks like that assert is not related to the VIMAGE patch. Works fine now since half an hour. Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. I've had a machine running a linux guest for almost a day, bridging with a VIMAGE kernel, while capturing traffic on the virtual interface (and performing a few other tasks) -- so far, so good. No panics, and no anomalies. I surely don't know what the above mentioned assert is about; I haven't seen such a panic myself. Thanks to everyone involved! I have committed it now to our blueports repository and the patch will come together with the next major VirtualBox update to 4.0.x. http://svn.bluelife.at/index.cgi/blueports/revision/?rev=1264 It got also reviewed from upstream and it looks fine so far. Will hopefully be committed soon. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? -Brandon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, Mar 2, 2011 at 2:52 PM, Bernhard Froehlich de...@bluelife.at wrote: On Wed, 02 Mar 2011 21:31:45 +0100, Bernhard Froehlich wrote: On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) It looks like that assert is not related to the VIMAGE patch. Works fine now since half an hour. Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. I've had a machine running a linux guest for almost a day, bridging with a VIMAGE kernel, while capturing traffic on the virtual interface (and performing a few other tasks) -- so far, so good. No panics, and no anomalies. I surely don't know what the above mentioned assert is about; I haven't seen such a panic myself. -Brandon ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Wed, Feb 2, 2011 at 8:06 PM, Julian Elischer jul...@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 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.
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 = curthread;
struct vnet *v = TD_TO_VNET(td);
struct ucred *cred = CRED_TO_VNET(td-ucred);
struct vnet *td_vnet = td-td_vnet;
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
Maybe something wrong with how I declare my wtap_ioctl:
static struct cdevsw wtap_cdevsw = {
.d_version =D_VERSION,
.d_flags = 0,
.d_ioctl = wtap_ioctl,
.d_name = 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 Elischerjul...@freebsd.org
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
--
//Monthadar Al Jaberi
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net 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.
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 = wtap
...
SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c
.include bsd.kmod.mk
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+= opt_global.h
.if defined(KERNBUILDDIR)
MKDEP= -include ${KERNBUILDDIR}/opt_global.h
.else
CFLAGS+= -include opt_global.h
MKDEP= -include opt_global.h
opt_global.h:
echo #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
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://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-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 12:18 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
On Thu, 3 Feb 2011, Monthadar Al Jaberi wrote:
On Thu, Feb 3, 2011 at 11:59 AM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net 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.
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 = wtap
...
SRCS = if_wtap_module.c if_wtap.c if_medium.c hal.c
.include bsd.kmod.mk
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+= opt_global.h
.if defined(KERNBUILDDIR)
MKDEP= -include ${KERNBUILDDIR}/opt_global.h
.else
CFLAGS+= -include opt_global.h
MKDEP= -include opt_global.h
opt_global.h:
echo #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
--
Bjoern A. Zeeb You have to have visions!
ks Going to jail sucks -- bz All my daemons like it!
http://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-unsubscr...@freebsd.org
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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.txtREV=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 Elischerjul...@freebsd.org 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 Elischerjul...@freebsd.org 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,,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
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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.txtREV=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 Elischerjul...@freebsd.org 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 Elischerjul...@freebsd.org 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 @
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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 jul...@freebsd.org 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 -- //Monthadar Al Jaberi ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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 Elischerjul...@freebsd.org 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 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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,,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 0xf, 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 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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,,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 0xf, 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-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
On Tue, Feb 1, 2011 at 6:25 PM, Julian Elischer jul...@freebsd.org 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,,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 0xf, 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 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
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 Elischerjul...@freebsd.org 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,,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 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags=
Re: VirtualBox + VIMAGE
On Thu, 27 Jan 2011 00:19:57 +0100 Bernhard Froehlich wrote: BF http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff BF I've integrated it a bit better into the VirtualBox build system, added BF the ports stuff and updated the patch for VirtualBox 4.0.2. Thanks! BF It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere BF check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for BF VIMAGE in the #if defined line or is this already done somewhere deep in BF the included headers? All magic is in net/vnet.h :-) -- Mikolaj Golub ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Tue, 25 Jan 2011 18:13:43 -0800, Julian Elischer wrote: On 1/25/11 1:06 PM, Mikolaj Golub wrote: On Sun, 23 Jan 2011 23:44:41 -0800 Julian Elischer wrote: JE On 1/23/11 6:33 AM, Mikolaj Golub wrote: As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see the attached patch). This has fixed the issue for me and now I am happily running both VNET jails and VirtualBox machines on my desktop. But the way I fixed the issue looks hackish for me. Could someone suggest a better solution? JE this is probably at east partially the correct solution. JE Usually you should also set the value back to its previous value when JE you leave that code as well. Thank you for the comments. Actually the patch contained CURVNET_RESTORE() too. I just did not mentioned it :-). So if it looks like right solution here is an improved version of the patch: vnet to switch is taken from thread's ucred (on interface initialization) or from ifp-if_vnet. yes I like it.. Now you just need a port person to patch the port :-) Sounds like it's my turn now. Which FreeBSD version is required to be able to use it? Is VIMAGE enabled per default and what happens if VIMAGE is disabled - does it at least build fine with that patch? For Mikolaj Golub to get this patch upstream we need that you either agree that his patch is under the MIT License or sign a Sun Contributors Agreement. Then we can submit that patch upstream or you can do it yourself if you prefer. Read here: http://www.virtualbox.org/wiki/Contributor_information -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote:
BF Sounds like it's my turn now. Which FreeBSD version is required to be
BF able to use it?
As Bjoern noted it is for __FreeBSD_version = 800500.
BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled -
BF does it at least build fine with that patch?
We have VIMAGE disabled by default.
I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile:
.if defined(VIMAGE)
CFLAGS += -DVIMAGE
.endif
So to build the driver for VIMAGE enabled kernel one should run
VIMAGE=1 make
If VIMAGE variable is not defined the module for VIMAGE disabled kernel will
be built.
I am not familiar with VBox build process so there might be a better solution.
I suppose we should have an option in ports, something:
.if ${OSVERSION} 800500
OPTIONS+=VIMAGE Build for VIMAGE kernel off
.endif
and if it is on set VIMAGE make environment variable. Or may be you have
a better solution.
BF For Mikolaj Golub to get this patch upstream we need that you either
BF agree that his patch is under the MIT License or sign a Sun Contributors
BF Agreement. Then we can submit that patch upstream or you can do it
BF yourself if you prefer. Read here:
BF http://www.virtualbox.org/wiki/Contributor_information
MIT License is ok.
It would be very nice of you if you submitted the patch upstream :-). If
nobody do this then I will try to submit it myself.
--
Mikolaj Golub
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, Jan 26, 2011 at 8:25 AM, Mikolaj Golub to.my.troc...@gmail.com wrote:
[SNIP]
I suppose we should have an option in ports, something:
.if ${OSVERSION} 800500
OPTIONS+= VIMAGE Build for VIMAGE kernel off
.endif
and if it is on set VIMAGE make environment variable. Or may be you have
a better solution.
As of r217203 on 9-CURRENT and r217403 on 8-STABLE, VIMAGE is
announced as a feature via sysctl(8). Would it be possible to query
this value to decide how to build the module?
[SNIP]
-Brandon
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, 26 Jan 2011, Mikolaj Golub wrote: On Wed, 26 Jan 2011 14:18:03 + (UTC) Bjoern A. Zeeb wrote: BAZ On Wed, 26 Jan 2011, Mikolaj Golub wrote: On Wed, 26 Jan 2011 09:15:46 + (UTC) Bjoern A. Zeeb wrote: BAZ I think you should wrap the CURVNET changes in __FreeBSD_version BAZ checks so that the port, should it run elsewhere or on older FreeBSDs BAZ (if it runs there) not trouble people having to patch it away. BAZ #if defined(__FreeBSD_version) __FreeBSD_version = 800500 BAZ #endif BAZ might be a save bet. Thanks. Something like in the patch below? Note, I have not run this version yet. Will test it tonight or tomorrow. BAZ Well, you will need to include sys/param.h as well, and that only if BAZ you are on FreeBSD so you'll need an extra check for just that I BAZ guess. Not sure how vbox handles the all this in their guts. The file has already had '#include sys/param.h' among other includes. It just is not seen in the patch. The file is used only for FreeBSD driver so there is no need in extra check I think. Ok, if it's freebsd only, then what you had was fine. I have tested this latest version of the patch. It works for me. Cool. Thanks! -- Bjoern A. Zeeb You have to have visions! ks Going to jail sucks -- bz All my daemons like it! http://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-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Sun, 23 Jan 2011 23:44:41 -0800 Julian Elischer wrote:
JE On 1/23/11 6:33 AM, Mikolaj Golub wrote:
As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions
CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see
the
attached patch). This has fixed the issue for me and now I am happily
running
both VNET jails and VirtualBox machines on my desktop.
But the way I fixed the issue looks hackish for me. Could someone suggest a
better solution?
JE this is probably at east partially the correct solution.
JE Usually you should also set the value back to its previous value when
JE you leave that code as well.
Thank you for the comments. Actually the patch contained CURVNET_RESTORE()
too. I just did not mentioned it :-). So if it looks like right solution here
is an improved version of the patch: vnet to switch is taken from thread's
ucred (on interface initialization) or from ifp-if_vnet.
In case someone is interested in trying this patch, below are the
instructions
how to build VIMAGE safe vbox driver from ports:
cd /usr/ports/emulators/virtualbox-ose-kmod
make patch
cd work
patch -p0 /path/to/VirtualBox-3.2.12.VIMAGE.patch
cd ..
VIMAGE=1 make
--
Mikolaj Golub
diff -rpu VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile
--- VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile 2010-12-01 19:09:33.0 +0200
+++ VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile 2011-01-25 22:48:26.0 +0200
@@ -26,6 +26,10 @@ CFLAGS += -DRT_OS_FREEBSD -DIN_RING0 -DI
CFLAGS += -DRT_ARCH_AMD64
.endif
+.if defined(VIMAGE)
+ CFLAGS += -DVIMAGE
+.endif
+
SRCS = \
VBoxNetFlt-freebsd.c \
VBoxNetFlt.c \
diff -rpu VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c
--- VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2010-12-01 19:09:33.0 +0200
+++ VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2011-01-25 22:48:26.0 +0200
@@ -37,6 +37,7 @@
#include sys/module.h
#include sys/systm.h
#include sys/errno.h
+#include sys/jail.h
#include sys/kernel.h
#include sys/fcntl.h
#include sys/conf.h
@@ -51,6 +52,7 @@
#include net/if_dl.h
#include net/if_types.h
#include net/ethernet.h
+#include net/vnet.h
#include netgraph/ng_message.h
#include netgraph/netgraph.h
@@ -322,6 +324,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
struct m_tag *mtag;
bool fActive;
+CURVNET_SET_QUIET(ifp-if_vnet);
fActive = vboxNetFltTryRetainBusyActive(pThis);
NGI_GET_M(item, m);
@@ -346,6 +349,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
ether_demux(ifp, m);
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return (0);
}
mtx_lock_spin(pThis-u.s.inq.ifq_mtx);
@@ -363,6 +367,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
int rc = ether_output_frame(ifp, m);
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return rc;
}
mtx_lock_spin(pThis-u.s.outq.ifq_mtx);
@@ -377,6 +382,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return (0);
}
@@ -409,6 +415,7 @@ static void vboxNetFltFreeBSDinput(void
bool fDropIt = false, fActive;
PINTNETSG pSG;
+CURVNET_SET_QUIET(ifp-if_vnet);
vboxNetFltRetain(pThis, true /* fBusy */);
for (;;)
{
@@ -438,6 +445,7 @@ static void vboxNetFltFreeBSDinput(void
ether_demux(ifp, m);
}
vboxNetFltRelease(pThis, true /* fBusy */);
+CURVNET_RESTORE();
}
/**
@@ -452,6 +460,7 @@ static void vboxNetFltFreeBSDoutput(void
bool fDropIt = false, fActive;
PINTNETSG pSG;
+CURVNET_SET_QUIET(ifp-if_vnet);
vboxNetFltRetain(pThis, true /* fBusy */);
for (;;)
{
@@ -481,6 +490,7 @@ static void vboxNetFltFreeBSDoutput(void
ether_output_frame(ifp, m);
}
vboxNetFltRelease(pThis, true /* fBusy */);
+CURVNET_RESTORE();
}
/**
@@ -498,6 +508,7 @@ int vboxNetFltPortOsXmit(PVBOXNETFLTINS
int error;
ifp = (void *)ASMAtomicUoReadPtr((void * volatile *)pThis-u.s.ifp);
+CURVNET_SET_QUIET(ifp-if_vnet);
if (fDst INTNETTRUNKDIR_WIRE)
{
@@ -539,6 +550,7 @@ int vboxNetFltPortOsXmit(PVBOXNETFLTINS
m-m_pkthdr.rcvif = ifp;
ifp-if_input(ifp, m);
}
+CURVNET_RESTORE();
return VINF_SUCCESS;
}
@@ -556,6 +568,7 @@ int vboxNetFltOsInitInstance(PVBOXNETFLT
node_p node;
RTSPINLOCKTMP Tmp =
Re: VirtualBox + VIMAGE
On 1/25/11 1:06 PM, Mikolaj Golub wrote: On Sun, 23 Jan 2011 23:44:41 -0800 Julian Elischer wrote: JE On 1/23/11 6:33 AM, Mikolaj Golub wrote: As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see the attached patch). This has fixed the issue for me and now I am happily running both VNET jails and VirtualBox machines on my desktop. But the way I fixed the issue looks hackish for me. Could someone suggest a better solution? JE this is probably at east partially the correct solution. JE Usually you should also set the value back to its previous value when JE you leave that code as well. Thank you for the comments. Actually the patch contained CURVNET_RESTORE() too. I just did not mentioned it :-). So if it looks like right solution here is an improved version of the patch: vnet to switch is taken from thread's ucred (on interface initialization) or from ifp-if_vnet. yes I like it.. Now you just need a port person to patch the port :-) In case someone is interested in trying this patch, below are the instructions how to build VIMAGE safe vbox driver from ports: cd /usr/ports/emulators/virtualbox-ose-kmod make patch cd work patch -p0 /path/to/VirtualBox-3.2.12.VIMAGE.patch cd .. VIMAGE=1 make ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On 1/23/11 6:33 AM, Mikolaj Golub wrote: Hi, Sorry for cross posting, but this question concerns both VirtualBox and VIMAGE :-). I would like to be able to run VirtualBox on my desktop, with kernel compilled with VIMAGE, so I would use light vnet jails for FreeBSD VMs and VirtualBox for other OSes. Currently the system will crash if you try to use VirtualBox bridged networking under VIMAGE kernel. The crash may look like below: db bt Tracing pid 2349 tid 100239 td 0xc984b2d0 ifunit(c7e3b9ac,6f,c129e970,f8089984,c08d6dc0,...) at ifunit+0x33 vboxNetFltOsInitInstance(c7e3b810,0,8,7,c9aa6ae0,...) at vboxNetFltOsInitInstance+0x31 vboxNetFltFactoryCreateAndConnect(c9aa8cc8,c96636d4,c9664010,0,c966403c,...) at vboxNetFltFactory CreateAndConnect+0x1f7 _end(c7b11810,c962c238,3,c962c2b8,0,...) at 0xc9c0114f _end(c7b11810,c962c22c,f20,c0d31268,f8089a90,...) at 0xc9c01265 _end(c962c22c,0,0,c7b11810,c0cfe2fe,...) at 0xc9bbc775 _end(f808a000,fffd,28,c962c22c,0,...) at 0xc9bbd086 supdrvIOCtl(c10c5607,c12a0a40,c7b11810,c962c200,c0e81df8,...) at supdrvIOCtl+0x1af1 VBoxDrvFreeBSDIOCtl(c94efb00,c10c5607,c962c200,3,c984b2d0,...) at VBoxDrvFreeBSDIOCtl+0x1ea devfs_ioctl_f(c8e70118,c10c5607,c962c200,c9a82900,c984b2d0,...) at devfs_ioctl_f+0x10b kern_ioctl(c984b2d0,e,c10c5607,c962c200,1089cec,...) at kern_ioctl+0x1fd ioctl(c984b2d0,f8089cec,2b077000,1,c94ed2a8,...) at ioctl+0x134 syscallenter(c984b2d0,f8089ce4,c0c20e2d,c0e83290,0,...) at syscallenter+0x2a6 syscall(f8089d28) at syscall+0x4f Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282ae093, esp = 0xbf8b980c, ebp = 0xbf8b9828 --- So it crashes when a function (ifunit in this case) tries to access virtualized variable (V_ifnet in this case). The macro uses td-td_vnet for this, which should be set to current vnet, but for VBox driver threads it is NULL. As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see the attached patch). This has fixed the issue for me and now I am happily running both VNET jails and VirtualBox machines on my desktop. But the way I fixed the issue looks hackish for me. Could someone suggest a better solution? this is probably at east partially the correct solution. Usually you should also set the value back to its previous value when you leave that code as well. In case someone is interested in trying this patch, below are the instructions how to build VIMAGE safe vbox driver from ports: cd /usr/ports/emulators/virtualbox-ose-kmod make patch cd work patch -p0 /path/to/VirtualBox-3.2.12.VIMAGE.patch cd .. VIMAGE=1 make ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
VirtualBox + VIMAGE
Hi,
Sorry for cross posting, but this question concerns both VirtualBox and VIMAGE
:-).
I would like to be able to run VirtualBox on my desktop, with kernel compilled
with VIMAGE, so I would use light vnet jails for FreeBSD VMs and VirtualBox
for other OSes.
Currently the system will crash if you try to use VirtualBox bridged
networking under VIMAGE kernel.
The crash may look like below:
db bt
Tracing pid 2349 tid 100239 td 0xc984b2d0
ifunit(c7e3b9ac,6f,c129e970,f8089984,c08d6dc0,...) at ifunit+0x33
vboxNetFltOsInitInstance(c7e3b810,0,8,7,c9aa6ae0,...) at
vboxNetFltOsInitInstance+0x31
vboxNetFltFactoryCreateAndConnect(c9aa8cc8,c96636d4,c9664010,0,c966403c,...) at
vboxNetFltFactory
CreateAndConnect+0x1f7
_end(c7b11810,c962c238,3,c962c2b8,0,...) at 0xc9c0114f
_end(c7b11810,c962c22c,f20,c0d31268,f8089a90,...) at 0xc9c01265
_end(c962c22c,0,0,c7b11810,c0cfe2fe,...) at 0xc9bbc775
_end(f808a000,fffd,28,c962c22c,0,...) at 0xc9bbd086
supdrvIOCtl(c10c5607,c12a0a40,c7b11810,c962c200,c0e81df8,...) at
supdrvIOCtl+0x1af1
VBoxDrvFreeBSDIOCtl(c94efb00,c10c5607,c962c200,3,c984b2d0,...) at
VBoxDrvFreeBSDIOCtl+0x1ea
devfs_ioctl_f(c8e70118,c10c5607,c962c200,c9a82900,c984b2d0,...) at
devfs_ioctl_f+0x10b
kern_ioctl(c984b2d0,e,c10c5607,c962c200,1089cec,...) at kern_ioctl+0x1fd
ioctl(c984b2d0,f8089cec,2b077000,1,c94ed2a8,...) at ioctl+0x134
syscallenter(c984b2d0,f8089ce4,c0c20e2d,c0e83290,0,...) at syscallenter+0x2a6
syscall(f8089d28) at syscall+0x4f
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x282ae093, esp = 0xbf8b980c, ebp
= 0xbf8b9828 ---
So it crashes when a function (ifunit in this case) tries to access
virtualized variable (V_ifnet in this case). The macro uses td-td_vnet for
this, which should be set to current vnet, but for VBox driver threads it is
NULL.
As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions
CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see the
attached patch). This has fixed the issue for me and now I am happily running
both VNET jails and VirtualBox machines on my desktop.
But the way I fixed the issue looks hackish for me. Could someone suggest a
better solution?
In case someone is interested in trying this patch, below are the instructions
how to build VIMAGE safe vbox driver from ports:
cd /usr/ports/emulators/virtualbox-ose-kmod
make patch
cd work
patch -p0 /path/to/VirtualBox-3.2.12.VIMAGE.patch
cd ..
VIMAGE=1 make
--
Mikolaj Golub
diff -rpu VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile
--- VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile 2010-12-01 19:09:33.0 +0200
+++ VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile 2011-01-23 12:44:24.0 +0200
@@ -26,6 +26,10 @@ CFLAGS += -DRT_OS_FREEBSD -DIN_RING0 -DI
CFLAGS += -DRT_ARCH_AMD64
.endif
+.if defined(VIMAGE)
+ CFLAGS += -DVIMAGE
+.endif
+
SRCS = \
VBoxNetFlt-freebsd.c \
VBoxNetFlt.c \
diff -rpu VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c
--- VirtualBox-3.2.12_OSE.orig/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2010-12-01 19:09:33.0 +0200
+++ VirtualBox-3.2.12_OSE/src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 2011-01-23 12:14:19.0 +0200
@@ -51,6 +51,7 @@
#include net/if_dl.h
#include net/if_types.h
#include net/ethernet.h
+#include net/vnet.h
#include netgraph/ng_message.h
#include netgraph/netgraph.h
@@ -322,6 +323,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
struct m_tag *mtag;
bool fActive;
+CURVNET_SET_QUIET(vnet0);
fActive = vboxNetFltTryRetainBusyActive(pThis);
NGI_GET_M(item, m);
@@ -346,6 +348,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
ether_demux(ifp, m);
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return (0);
}
mtx_lock_spin(pThis-u.s.inq.ifq_mtx);
@@ -363,6 +366,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
int rc = ether_output_frame(ifp, m);
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return rc;
}
mtx_lock_spin(pThis-u.s.outq.ifq_mtx);
@@ -377,6 +381,7 @@ static int ng_vboxnetflt_rcvdata(hook_p
if (fActive)
vboxNetFltRelease(pThis, true /*fBusy*/);
+CURVNET_RESTORE();
return (0);
}
@@ -409,6 +414,7 @@ static void vboxNetFltFreeBSDinput(void
bool fDropIt = false, fActive;
PINTNETSG pSG;
+CURVNET_SET_QUIET(vnet0);
vboxNetFltRetain(pThis, true /* fBusy */);
for (;;)
{
@@ -438,6 +444,7 @@ static void vboxNetFltFreeBSDinput(void
