From julian at elischer.org Sun Aug 3 08:06:01 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 3 08:06:08 2008 Subject: Developers adding global variables. Message-ID: <489566F5.9040308@elischer.org> If you are adding globals to the networking code, (or if you have added soem globals in the last few months, could you make sure that I am aware of them? marko Zec and I are trying to keep teh Vimage tree in perforce in sync with -current but there is noo automatic way that we would be noticfied of the sudden appearance of a new global variable in the networking code. Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their proximity to another change. thanks Julian From rwatson at FreeBSD.org Sun Aug 3 10:32:17 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 10:48:55 2008 Subject: Developers adding global variables. In-Reply-To: <489566F5.9040308@elischer.org> References: <489566F5.9040308@elischer.org> Message-ID: On Sun, 3 Aug 2008, Julian Elischer wrote: > If you are adding globals to the networking code, (or if you have added soem > globals in the last few months, could you make sure that I am aware of them? > > marko Zec and I are trying to keep teh Vimage tree in perforce in sync with > -current but there is noo automatic way that we would be noticfied of the > sudden appearance of a new global variable in the networking code. > > Today I noticed tcp_do_ecn and tcp_ecn_maxretries but only because of their > proximity to another change. While not a universal solution, one technique you could use to catch things like this is to compare the set of symbols in a !virtualization kernel with those in a virtualization kernels, perhaps using nm(1), and compare that difference set over time. Not perfect, but it would allow you to look for things that have been missed. FWIW, I have no immediate plans to add any global variables to the network stack. Robert N M Watson Computer Laboratory University of Cambridge From bzeeb-lists at lists.zabbadoz.net Wed Aug 13 18:20:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Aug 13 18:20:14 2008 Subject: Advanced warning: virtualization work will be afoot (fwd) Message-ID: <20080813181858.L88849@maildrop.int.zabbadoz.net> FYI -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ---------- Forwarded message ---------- Date: Wed, 13 Aug 2008 17:59:51 +0100 (BST) From: Robert Watson To: current@FreeBSD.org Cc: arch@FreeBSD.org Subject: Advanced warning: virtualization work will be afoot Dear all: This weekend is the FreeBSD Developer Summit in Cambridge, UK, and one of the focuses of the meetings will be the on-going network stack virtualization. We hope to have several days in a row to focus on known issues, understand (and possible address) various concerns about the approach, and possibly expand the focus to further subsystems. We also hope to explore doing some amount of virtualization below the language level, and hopefully have the right set of people there to talk about that. With all this in mind, it may well be that we begin some of the heavy lifting on virtualization in the base Subversion tree, whereas to date this work has occurred almost entirely in Perforce. The outcome of the meetings will depend a lot on what we find and what progress we make, so this isn't exactly a "HEADS UP: Virtualization going into SVN", but it could well be that there is quite a bit of committing going on. Thanks, Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From bz at FreeBSD.org Sat Aug 16 10:21:03 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sat Aug 16 10:21:14 2008 Subject: V_HEADS UP (at short notice) kinda headsup.. (fwd) Message-ID: <20080816094619.G88849@maildrop.int.zabbadoz.net> Hi, this is THE HEADS UP in addition to Julian's HEADS UP a few weeks ago and Robert's mini-HEADS UP a few days ago. Your private changes for HEAD might be screwed by the the of this day (BST) as the first step of the VImage work should go in. You have been warned, we are going to accept the risk, talk to Peter in case you want to stop is this or sink the Isle of Albion within a few hours;-) /bz PS: if you are unlucky we'll prepare the 2nd stage for/on Monday. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ---------- Forwarded message ---------- Date: Sun, 08 Jun 2008 22:58:40 -0700 From: Julian Elischer To: FreeBSD Current , freebsd-virtualization@freebsd.org, Marko Zec Subject: kinda headsup.. At the BSDCAn devsummit we discussed how to proceed with committing Vimage to -current. the Milestones included something like: June 8 (today) Headsup.... June 15 commit changes that add macros for vnet (network module) and vinet(inet virtualisation) with macros defined in such a way to make 0 actual differences. provable by md5 etc. Documentat s/hostname/g//V_hostname/ #define V_hostname hostname 2 weeks settle time, next step prepared, tested and reviewed. June 29 Add changes to convert all globals to members of per-module structures. Done in a reversible way (i.e. compilable out). Macros defined so that depending on compile options structures or globals are used (one global structure). Performance implications of using structures are evaluated. Structures possibly tuned. Initialisation routines added, checked and tuned. example: #if VIMAGE_USE_STRUCTS #define V_hostname sys_globals.hostname ... #else #define V_hostname hostname ... #endif July 13 globals removed in vnet, vinet. ifdefs and compile option removed or scaled back to make code clean to read again. Destructor routines added where needed. Remaining "NULL Macros" (compile to nothing at this point) committed to reduce the size of the MEAT diffs. Review of Meat diffs formally under way for final comment. example: #define INIT_VNET_INET(x) /* nothing */ add "INIT_VNET_INET(curvnet);"(and similar) where needed. remove globals (e.g. 'hostname') July 21 JAIL+Vimage framework committed. e.g. add new syscall, program, etc. (part one of meat diffs) structures still only global instances. vimage inhansed jails can be created but act jus tlike normal jails? July 28 Ability to created > 1 vimage enabled. Vimage enhanced jails now have private network stacks etc. August start on converting more modules as needed and time allows. Marko and I have been working towards splitting up the current diffs (which do the whole thing) so allow this schedule to be followed. We may or may not be ready for the June 15 step by then, but if not it may be a week there-after. So this should be considered the heads-up. discussion will be on freebsd-virtualization@ and the perforce branch that we have as a current working system is branch 'vimage'. //depot/projects/vimage/... diffs can be found at: http://www.freebsd.org/~julian/vimage.diff and it are usually fairly up to date. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From julian at elischer.org Sun Aug 17 08:24:09 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 17 08:24:18 2008 Subject: next moves Message-ID: <48A7E024.3040705@elischer.org> My thoughts.. once commit2 is committed and effectively becomes -current, then commit3 and commit1 could be done, which would reduce the diff size more it: 1/ adds Marco's real include files and the real final definitions of V_ vars. 2/ adds a bunch of the final INIT_VNET_XXX macros in place to further reduce the size of the binaries 3/ introduces (but does not yet use) the structures that hold the globals after this we should STILL see no real binary change. If we could get the same horsepower on commit3 that we have seen on commit2 then I see no reason it would not be in a committable state in a few days.. the next step after that would be to do the vimage-commit branch, which after the commit3 branch was added would be a small additional step. It adds a few more of the macros but is aimed at pure diff reduction it may follow just a day or so after commit3. It's an incremental change, but is derived from the vimage branch rather than from the commit2 (mechanical) branch, and basically just acts as a shim in diff to get us a bit closer to where we are going. Once those branches have been committed I would suggest a step where turnign on VIMAGE actually doesn't enable vimage entirely, but simply enables global versions of the structures mentionned above. This would be the step that Brook was looking for. constructors woudl be used. Destructors less so. We would do some timing tests at this point to quantify the relative speeds of global and "structified" versions. As ALC has pointed out, it is possible we may want to tune the structures. The last vimage step would be to switch on the virtualisatin framework and commit the remainder of the vimage branch (modulo cleanups and what we learn in the mean while). after that I think we turn our attention to the jail sets work that James is doing.. From bz at FreeBSD.org Sun Aug 17 23:50:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sun Aug 17 23:50:26 2008 Subject: V_HEADS UP II. In-Reply-To: <20080816094619.G88849@maildrop.int.zabbadoz.net> References: <20080816094619.G88849@maildrop.int.zabbadoz.net> Message-ID: <20080817234400.X88849@maildrop.int.zabbadoz.net> On Sat, 16 Aug 2008, Bjoern A. Zeeb wrote: Hi, > this is THE HEADS UP in addition to Julian's HEADS UP a few weeks ago > and Robert's mini-HEADS UP a few days ago. > > Your private changes for HEAD might be screwed by the the of this day > (BST) as the first step of the VImage work should go in. > > You have been warned, we are going to accept the risk, talk to Peter > in case you want to stop is this or sink the Isle of Albion within a > few hours;-) Okay, Britain still above sea levels, mostly... The first stage commit of vimage went in. In case you are changing sys/ and you are touching anything related to globals make sure you get it right! > PS: if you are unlucky we'll prepare the 2nd stage for/on Monday. We are most likely going to start on that and it's hopefully going to hit the tree within a week. This is the HeADS UP. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From bz at FreeBSD.org Mon Aug 18 00:25:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 18 00:25:14 2008 Subject: V_HEADS UP II. In-Reply-To: <20080817234400.X88849@maildrop.int.zabbadoz.net> References: <20080816094619.G88849@maildrop.int.zabbadoz.net> <20080817234400.X88849@maildrop.int.zabbadoz.net> Message-ID: <20080818001908.W88849@maildrop.int.zabbadoz.net> On Sun, 17 Aug 2008, Bjoern A. Zeeb wrote: > On Sat, 16 Aug 2008, Bjoern A. Zeeb wrote: > > Hi, > >> this is THE HEADS UP in addition to Julian's HEADS UP a few weeks ago >> and Robert's mini-HEADS UP a few days ago. >> >> Your private changes for HEAD might be screwed by the the of this day >> (BST) as the first step of the VImage work should go in. >> >> You have been warned, we are going to accept the risk, talk to Peter >> in case you want to stop is this or sink the Isle of Albion within a >> few hours;-) > > Okay, Britain still above sea levels, mostly... > > The first stage commit of vimage went in. In case you are changing > sys/ and you are touching anything related to globals make sure you get > it right! Sorry, this was not helpful... (it's late here, local time). There is a write up from Julian and Marko in perforce at //depot/projects/vimage/porting_to_vimage.txt You can also get to that using the web frontends, either http://perforce.freebsd.org/ or http://p4web.freebsd.org/ which would probably be a good thing to start with and it could be further enahnced as more things would need explanation. If in doubt there is the freebsd-virtualization@ mailing list where you could ask as well or try to ping any of the reviewers of the first stage commit. >> PS: if you are unlucky we'll prepare the 2nd stage for/on Monday. > > We are most likely going to start on that and it's hopefully going to > hit the tree within a week. This is the HeADS UP. Good night /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From bz at FreeBSD.org Mon Aug 18 13:45:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 18 13:45:13 2008 Subject: next moves In-Reply-To: <48A7E024.3040705@elischer.org> References: <48A7E024.3040705@elischer.org> Message-ID: <20080818133733.B88849@maildrop.int.zabbadoz.net> On Sun, 17 Aug 2008, Julian Elischer wrote: > My thoughts.. "Our" ``thoughts'' (we are not the Borg;) are on the wiki now: http://wiki.freebsd.org/Image/Notes200808DevSummit and are updated, enhanced and refined as we move on. I think we have incoorportaed most of your ideas and sometimes defined them in more detail. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Mon Aug 18 14:07:45 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 18 14:07:58 2008 Subject: Next p4 integ for vimage branch In-Reply-To: <200808181219.20045.zec@freebsd.org> References: <200808181219.20045.zec@freebsd.org> Message-ID: <48A98231.2080503@elischer.org> Marko Zec wrote: > I'm half through resolving the conflicts there and probably won't be > done with this until tomorrow afternoon after returning home. Will do > the others branches after vimage integ is done. > > Marko commit3 should not be a problem since it is based off commit2 I was going to offer to help with vimage-commit however is base of 'vimage' so merging vimage should allow you to to vimage-commit by cross itegratingthe changes.. then cross integrating between vimage-commit and vimage-commit3 should be possible to merge them.. (the reason that vimage-commit and vimage-commit3 both exist is as a check on eaxh other.. vimage-commit is a cut-down version of vimage, while vmage-commit3 is a built up version of vimage-commit2, but they shuld contain about the same information.. it was my way of comparing 'vimage' with the (originally) machine generated vimage-commit2. so if we merge -current into vomage, teh same changes should also apply into vimage-commit. which should then become very close to vimage-commit3. I vwould then merge those two, and call that teh next commit in other workds I think the next commit candidate (which will still make no actual change to the binaries should be the integration product of vimage-commmit and vimage-commit3 both of which should have been updated to take into account the commit just done. that will be "just about everything else we can do without changing hte binary". I think this should eb the aim of the next commit. "get as much in as we can without actually doing anything" it massively reduces teh diff and puts us in a really god possition for having the MEAT of the diff more visible and available for review. it will also make the differences with Jamie more clear. From bz at FreeBSD.org Mon Aug 18 23:21:39 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Mon Aug 18 23:21:45 2008 Subject: next moves In-Reply-To: <20080818133733.B88849@maildrop.int.zabbadoz.net> References: <48A7E024.3040705@elischer.org> <20080818133733.B88849@maildrop.int.zabbadoz.net> Message-ID: <20080818231704.R66593@maildrop.int.zabbadoz.net> On Mon, 18 Aug 2008, Bjoern A. Zeeb wrote: Hi, > On Sun, 17 Aug 2008, Julian Elischer wrote: > >> My thoughts.. > > "Our" ``thoughts'' (we are not the Borg;) are on the wiki now: > > http://wiki.freebsd.org/Image/Notes200808DevSummit I have updated things wrt. to Jamie's mgmt work there. Basic summary of the changes as of the majority opinion: * We want an explicit opt-in for recursive changes (default: only apply to the addressed jail) * In kernel structure will be called whatever they will be called. He who implements decides. I'll be travelling most of tomorrow and do not expect to be online before Thu evening local time so in case there are further things, Robert or others might want to follow-up. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Wed Aug 20 08:12:33 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Aug 20 08:12:40 2008 Subject: report and comment Message-ID: <48ABD1EF.5060307@elischer.org> I have MOSTLY merged the last commit into all the p4 branches.. progress should be good towards commit 1.5 something I just noticed.... in sys/netinet/tcp_subr.c ================================================ [...] #endif * Locking of the global variables isn_secret, isn_last_reseed, isn_offset, * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock. In * general, this means holding an exclusive (write) lock. */ #define ISN_BYTES_PER_SECOND 1048576 #define ISN_STATIC_INCREMENT 4096 #define ISN_RANDOM_INCREMENT (4096 - 1) #ifndef VIMAGE static u_char isn_secret[32]; static int isn_last_reseed; static u_int32_t isn_offset, isn_offset_old; static MD5_CTX isn_ctx; #endif tcp_seq tcp_new_isn(struct tcpcb *tp) { [...] ================================================ and in sys/contrib/pf/net/pf_subr.c ================================================ [...] * Locking of the global variables isn_secret, isn_last_reseed, isn_offset, * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock. In * general, this means holding an exclusive (write) lock. */ #define ISN_BYTES_PER_SECOND 1048576 #define ISN_STATIC_INCREMENT 4096 #define ISN_RANDOM_INCREMENT (4096 - 1) #ifndef VIMAGE static u_char isn_secret[32]; static int isn_last_reseed; static u_int32_t isn_offset; static MD5_CTX isn_ctx; #endif u_int32_t pf_new_isn(struct pf_state *s) { [...] ===================================================== so we have the same global variables, static, in 2 places.. so one set should go in the pf vars and the other in the inet vars. The first answers I think of are: 1/ rename one set 2/ make one of them a VV_ macro that goes elsewhere. anyone have other suggestions? From julian at elischer.org Wed Aug 20 08:18:20 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Aug 20 08:18:38 2008 Subject: report and comment In-Reply-To: <48ABD1EF.5060307@elischer.org> References: <48ABD1EF.5060307@elischer.org> Message-ID: <48ABD349.6030701@elischer.org> Julian Elischer wrote: > I have MOSTLY merged the last commit into > all the p4 branches.. > > progress should be good towards commit 1.5 > > > something I just noticed.... > > in sys/netinet/tcp_subr.c > ================================================ > [...] > #endif * Locking of the global variables isn_secret, isn_last_reseed, > isn_offset, > * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock. In > * general, this means holding an exclusive (write) lock. > */ > > #define ISN_BYTES_PER_SECOND 1048576 > #define ISN_STATIC_INCREMENT 4096 > #define ISN_RANDOM_INCREMENT (4096 - 1) > > #ifndef VIMAGE > static u_char isn_secret[32]; > static int isn_last_reseed; > static u_int32_t isn_offset, isn_offset_old; > static MD5_CTX isn_ctx; > #endif > > tcp_seq > tcp_new_isn(struct tcpcb *tp) > { > [...] > ================================================ > > and in sys/contrib/pf/net/pf_subr.c > > ================================================ > [...] > * Locking of the global variables isn_secret, isn_last_reseed, isn_offset, > * isn_offset_old, and isn_ctx is performed using the TCP pcbinfo lock. In > * general, this means holding an exclusive (write) lock. > */ > > #define ISN_BYTES_PER_SECOND 1048576 > #define ISN_STATIC_INCREMENT 4096 > #define ISN_RANDOM_INCREMENT (4096 - 1) > > #ifndef VIMAGE > static u_char isn_secret[32]; > static int isn_last_reseed; > static u_int32_t isn_offset; > static MD5_CTX isn_ctx; > #endif > > u_int32_t > pf_new_isn(struct pf_state *s) > { > [...] > ===================================================== > > so we have the same global variables, static, in 2 places.. > so one set should go in the pf vars and the other in the inet > vars. The first answers I think of are: > > > 1/ rename one set > 2/ make one of them a VV_ macro that goes elsewhere. looking at the code better... I see the entire function is about the same.. 3/ remove the duplicated code in pf and call the one in tcp_subr.c from both places.. > > anyone have other suggestions? > > > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From baigsabeeh at gmail.com Thu Aug 21 02:37:17 2008 From: baigsabeeh at gmail.com (Sabeeh Baig) Date: Thu Aug 21 02:37:25 2008 Subject: Xen Status Message-ID: Is Xen DomU support usable and complete? Also, is Xen Dom0 on the roadmap? Good virtualization framework/software regardless of what technology it uses is one thing that FreeBSD lacks, but is often required by FreeBSD's main user group and even smaller user groups. [I don't mean to sound pushy. I'd help, but I don't know where to start, and I'm still learning C right now, so I don't think I'd be of that much help working on something so big with so little experience.] -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Sabeeh Ahmed Baig From ady at freebsd.ady.ro Thu Aug 21 07:16:04 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Thu Aug 21 07:16:18 2008 Subject: Xen Status In-Reply-To: References: Message-ID: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> Hi, Xen (DomU support) has recently started its life in HEAD (FreeBSD-CURRENT). Follow this thread under freebsd-hackers: http://docs.freebsd.org/cgi/mid.cgi?g8962l$q9l$1 I agree with you that we need more virtualization offerings in order to keep the [Free]BSD platform interesting for the users. I guess we'll have to push harder vendors like VMware, Sun (xVM/VirtualBox), etc. ... For VMware support, see also : http://www.rofug.ro/article.php/fbsd_as_vmware_host_vote Regards, Adrian. On Thu, Aug 21, 2008 at 4:12 AM, Sabeeh Baig wrote: > Is Xen DomU support usable and complete? > > Also, is Xen Dom0 on the roadmap? Good virtualization > framework/software regardless of what technology it uses is one thing > that FreeBSD lacks, but is often required by FreeBSD's main user group > and even smaller user groups. [I don't mean to sound pushy. I'd > help, but I don't know where to start, and I'm still learning C right > now, so I don't think I'd be of that much help working on something so > big with so little experience.] > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to understand the simplicity." > > Sabeeh Ahmed Baig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > From unixmania at gmail.com Thu Aug 21 13:13:06 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Aug 21 13:13:18 2008 Subject: Xen Status In-Reply-To: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> References: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> Message-ID: On Thu, Aug 21, 2008 at 3:51 AM, Adrian Penisoara wrote: > Hi, > > Xen (DomU support) has recently started its life in HEAD (FreeBSD-CURRENT). > > Follow this thread under freebsd-hackers: > > http://docs.freebsd.org/cgi/mid.cgi?g8962l$q9l$1 > > I agree with you that we need more virtualization offerings in order > to keep the [Free]BSD platform interesting for the users. I guess > we'll have to push harder vendors like VMware, Sun (xVM/VirtualBox), > etc. ... > For VMware support, see also : > http://www.rofug.ro/article.php/fbsd_as_vmware_host_vote > > Regards, > Adrian. I'd not expect anything from VMware in the foreseeable future. VirtualBox is open source now but someone with enough knowledge and time would have to work on porting it to FreeBSD. The hardest part of the work would be porting the kernel module, I guess. (CC to the list, now) -- If you think things can't get worse it's probably only because you lack sufficient imagination. From baigsabeeh at gmail.com Thu Aug 21 14:23:44 2008 From: baigsabeeh at gmail.com (Sabeeh Baig) Date: Thu Aug 21 14:23:52 2008 Subject: Xen Status In-Reply-To: References: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> Message-ID: I think the developers over at Sun are working on porting VirtualBox to FreeBSD, or at least providing support for it in the open source edition. There are indications on the VBox website, even a page dedicated to progress. It does compile on FreeBSD, but doesn't function because of the lack of a kernel driver. The problem with VirtualBox is that it runs Linux guests well, but all other operating systems are a hit or miss. It itself is somewhat of a work-in-progress. According to that thread, DomU is a starting point that will lead to Dom0 support some time down the road, right? I don't think VMWare will provide a native version for FreeBSD. I don't think they provide anything for other Unixes such as Solaris or AIX, which also have dominance in the server market. VMWare would have considerable potential buyers with those markets, but they don't provide anything for them, so FreeBSD is a long shot. However, that thread on VMWare forums does mention updating the port. How hard would that be to do? Is there a reason that it's essentially been abandoned? Sabeeh On Thu, Aug 21, 2008 at 8:48 AM, Carlos A. M. dos Santos wrote: > On Thu, Aug 21, 2008 at 3:51 AM, Adrian Penisoara wrote: >> Hi, >> >> Xen (DomU support) has recently started its life in HEAD (FreeBSD-CURRENT). >> >> Follow this thread under freebsd-hackers: >> >> http://docs.freebsd.org/cgi/mid.cgi?g8962l$q9l$1 >> >> I agree with you that we need more virtualization offerings in order >> to keep the [Free]BSD platform interesting for the users. I guess >> we'll have to push harder vendors like VMware, Sun (xVM/VirtualBox), >> etc. ... >> For VMware support, see also : >> http://www.rofug.ro/article.php/fbsd_as_vmware_host_vote >> >> Regards, >> Adrian. > > I'd not expect anything from VMware in the foreseeable future. > > VirtualBox is open source now but someone with enough knowledge and > time would have to work on porting it to FreeBSD. The hardest part of > the work would be porting the kernel module, I guess. > > (CC to the list, now) > > -- > If you think things can't get worse it's probably only > because you lack sufficient imagination. > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Sabeeh Ahmed Baig From silby at silby.com Fri Aug 22 01:03:45 2008 From: silby at silby.com (Mike Silbersack) Date: Fri Aug 22 01:03:52 2008 Subject: report and comment In-Reply-To: <48ABD349.6030701@elischer.org> References: <48ABD1EF.5060307@elischer.org> <48ABD349.6030701@elischer.org> Message-ID: On Wed, 20 Aug 2008, Julian Elischer wrote: >> so we have the same global variables, static, in 2 places.. >> so one set should go in the pf vars and the other in the inet >> vars. The first answers I think of are: >> >> >> 1/ rename one set >> 2/ make one of them a VV_ macro that goes elsewhere. > > looking at the code better... I see the entire function is about the same.. > > 3/ remove the duplicated code in pf and call the one in tcp_subr.c > from both places.. The code originally came from tcp_subr.c, then Max copied it over to pf to improve pf's behavior. I'm guessing that he intentionally left them seperate so that the host part of the TCP stack wasn't interacting with the firewall part of the system. Renaming the variables in the pf copy is probably a better solution. -Mike From bzeeb-lists at lists.zabbadoz.net Fri Aug 22 09:50:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Aug 22 09:50:14 2008 Subject: report and comment In-Reply-To: References: <48ABD1EF.5060307@elischer.org> <48ABD349.6030701@elischer.org> Message-ID: <20080822094405.W66593@maildrop.int.zabbadoz.net> On Thu, 21 Aug 2008, Mike Silbersack wrote: Hi, > On Wed, 20 Aug 2008, Julian Elischer wrote: > >>> so we have the same global variables, static, in 2 places.. >>> so one set should go in the pf vars and the other in the inet >>> vars. The first answers I think of are: >>> >>> >>> 1/ rename one set This is exactly what we did with others. See follow-up commit the next day. >>> 2/ make one of them a VV_ macro that goes elsewhere. >> >> looking at the code better... I see the entire function is about the same.. >> >> 3/ remove the duplicated code in pf and call the one in tcp_subr.c >> from both places.. > > The code originally came from tcp_subr.c, then Max copied it over to pf to > improve pf's behavior. I'm guessing that he intentionally left them seperate > so that the host part of the TCP stack wasn't interacting with the firewall > part of the system. Renaming the variables in the pf copy is probably a > better solution. I do not understand what this is actually about as pf is NOT virtualized yet. The only V_ changes in there should be, according to Marko, be in there to make the code actually compile with the rest of the V_ changes. In case we touched a shadowed file local static global variable in there I would suspect that this might be an error from the original script run and the change should be reverted. I'll have a look at this tonight. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From lists at stringsutils.com Fri Aug 22 15:40:17 2008 From: lists at stringsutils.com (Francisco Reyes) Date: Fri Aug 22 15:41:36 2008 Subject: Xen Status In-Reply-To: References: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> Message-ID: <2b9487b4c499857e8e33b55cc3556b73@stringsutils.com> On 10:23 am 08/21/08 "Sabeeh Baig" wrote: > I don't think VMWare will provide a native version for FreeBSD. I > don't think they provide anything for other Unixes such as Solaris or > AIX, which also have dominance in the server market. I think Xen and Virtualbox are our best bets. Specially since that would give those two projects added leverage against the entrenched VMware market. From lists at stringsutils.com Fri Aug 22 15:40:17 2008 From: lists at stringsutils.com (Francisco Reyes) Date: Fri Aug 22 15:41:36 2008 Subject: Xen Status In-Reply-To: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> References: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> Message-ID: <02be032c57653d45e20abd8bcac3d70a@stringsutils.com> On 2:51 am 08/21/08 "Adrian Penisoara" wrote: > I agree with you that we need more virtualization offerings in order > to keep the [Free]BSD platform interesting for the users. I guess I wrote to the FreeBSD foundation asking them if they were doing anything about virtualization and their answer was that they has requested from the community project suggestions for them to fund. I am thinking whether we should approach the developers in VirtualBox (which I think was purchased by Sun..) and see if they have anyone what could work on a FreeBSD port and have the FreeBSD foundation pay for the work. I for one would definitely donate to the FreeBSD foundation towards virtualization work. From julian at elischer.org Fri Aug 22 16:31:31 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Aug 22 16:31:50 2008 Subject: Magic symlinks redux In-Reply-To: <20080822150728.GB57443@lor.one-eyed-alien.net> References: <20080822090448.GB57441@onelab2.iet.unipi.it> <48AE89DC.9080408@yandex.ru> <20080822120525.GA1366@haakonia.hitnet.RWTH-Aachen.DE> <20080822145616.GA61094@onelab2.iet.unipi.it> <20080822150728.GB57443@lor.one-eyed-alien.net> Message-ID: <48AEE9DF.3000400@elischer.org> Brooks Davis wrote: > On Fri, Aug 22, 2008 at 04:56:16PM +0200, Luigi Rizzo wrote: >> On Fri, Aug 22, 2008 at 02:05:26PM +0200, Christian Brueffer wrote: >>> On Fri, Aug 22, 2008 at 12:24:41PM +0200, Ivan Voras wrote: >> ... >>>> This patch is huge. As far as I can tell DragonflyBSD has a whole >>>> framework dedicated to varsyms, spread across a fair part of the kernel >>>> and with at least one special userland utility. It allows the operator >>>> to define his own variables that can be used in the substitutions, and I >>>> don't see that it predefines "special" variables like "uid" and >>>> "hostname". It's not necessarily a bad solution but I consider it overkill. >> ... >>> Brooks has a varsym port in p4, see //depot/user/brooks/varsym/ >> this also seems to be based on Dragonfly's code, quite intrusive. > > This code adds one global symbol, one function call in the vfs code, > and two pointers to struct proc. For that we get a system which is > significantly more flexible than the NetBSD code. > > While the simplicity of the NetBSD code is somewhat attractive, the > fact that variables can not be defined renders it useless for my > purposes which are providing partial file system virtulization for > computing job/sessions where I need to key off of externally derived job > IDs or job specific temporary paths. then this needs to be put on the virtualisation mailing list (CC'd) as Jamie and Vereo have another implementationt eh yare getting ready I thing.. (with considerably different proporties especially designed for use with virtualisation) Verio have thsi in production. > > -- Brooks > >> I am playing with a rewrite (attached below) of the original patch, >> which fixes at least one memory leak and addresses some of the >> issues that i mentioned in this thread (abuse of macros, performance, >> behaviour on errors, etc.). >> >> (i haven't looked up yet the original copyright but i guess it >> is from netbsd...) >> >> cheers >> From ady at freebsd.ady.ro Fri Aug 22 21:13:36 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Fri Aug 22 21:13:44 2008 Subject: Xen Status In-Reply-To: <02be032c57653d45e20abd8bcac3d70a@stringsutils.com> References: <78cb3d3f0808202351s2ff2aa04va6ba44cffb28cdf7@mail.gmail.com> <02be032c57653d45e20abd8bcac3d70a@stringsutils.com> Message-ID: <78cb3d3f0808221413l3f733de6j6e970f857e7817dd@mail.gmail.com> Hi, On Fri, Aug 22, 2008 at 5:21 PM, Francisco Reyes wrote: > On 2:51 am 08/21/08 "Adrian Penisoara" wrote: >> I agree with you that we need more virtualization offerings in order >> to keep the [Free]BSD platform interesting for the users. I guess > > I wrote to the FreeBSD foundation asking them if they were doing anything > about virtualization and their answer was that they has requested from the > community project suggestions for them to fund. Right, heard about budgeting for projects. Nice twist to get funded for such work -- maybe we could put something on the table, but we need strong references. > > I am thinking whether we should approach the developers in VirtualBox > (which I think was purchased by Sun..) and see if they have anyone what Correct, Sun bought the product and they are offering it as dual products (OSE sourcecode and xVM packaged binaries; note: xVM is free only for Personal Use / evaluation). > could work on a FreeBSD port and have the FreeBSD foundation pay for the > work. I for one would definitely donate to the FreeBSD foundation towards > virtualization work. > I seem to remember some discussions about people trying to work on this. If funding is also available then I guess there are more chances to get something finished. I will also lookup on this. Regards, Adrian. From kmacy at freebsd.org Sat Aug 23 05:10:55 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sat Aug 23 05:11:02 2008 Subject: xen update Message-ID: <3c1674c90808222138v12d7b9f8q5230273b076b3b43@mail.gmail.com> For any of you who might not be on -current or -hackers: ==================================== Basic Xen support for 32-bit in PAE mode is in CVS. Please see the wiki for general information: http://wiki.freebsd.org/FreeBSD/Xen Please be forewarned that I am not claiming that this is production-ready. There are many known limitations. If you would like to take it for a test drive and report bugs please give it a spin. Thanks, Kip From pfgshield-freebsd at yahoo.com Sat Aug 23 19:41:47 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Sat Aug 23 19:42:49 2008 Subject: VirtualBox (was Re: Xen Status) Message-ID: <170952.47920.qm@web32701.mail.mud.yahoo.com> On 11:23 am 08/22/08 "Francisco Reyes" wrote: > I am thinking whether we should approach the developers in VirtualBox > (which I think was purchased by Sun..) and see if they have anyone what > could work on a FreeBSD port and have the FreeBSD foundation pay for the > work. I for one would definitely donate to the FreeBSD foundation towards > virtualization work. I am using VirtualBox on Vista to run OpenSolaris and PC-BSD .. it is great; it's pretty much comparable to qemu with acceleration, but better. Unfortunately the FreeBSD port is stuck: at some point the basic stuff was working but the independent guy that was working on it lost interest. The big step is porting the kernel components that need FreeBSD specific knowledge. I am not sure if we need someone from SUN/VB to do the port, maybe a FreeBSD kqemu hacker would be the right person. Pedro. ps. I updated devel/bin86 with amd64 support (PR ports/125614) in the hope that it will be useful for such effort. __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From bzeeb-lists at lists.zabbadoz.net Sun Aug 24 14:25:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Aug 24 14:25:14 2008 Subject: panic in vimage/jamie_jail_set Message-ID: <20080824141835.K66593@maildrop.int.zabbadoz.net> Hi, I had a jamie_jail_set kernel running from db> x/s version version: FreeBSD 8.0-CURRENT #0: Fri Aug 15 10:01:11 UTC 2008 ... and it paniced while standing idle. I am not sure if that had been fixed in the vimage branch but not integrated into jamie_jail_set or if this was a different issue to what kris had seen? Unfortunately the console hasn't been to reliable, so this is what I have: panic: in ../../../netinet/tcp_usrreq.c:1281 tcp_ctloutput()^M^@ vnet=0xc7067000 curvnet=0^M^@ cpuid = 0^M^@ KDB: enter: panic^M^@ [thread pid 852 tid 100051 ]^M^@ Stopped at kdb_enter+0x3a: movl $0,kdb_why^M^@ Tracing pid 852 tid 100051 td 0xc74f5d20 kdb_enter(c0b04531,c0b04531,c0b05c88,c6f4b59c,0,...) at kdb_enter+0x3a panic(c0b05c88,c0b1cb7f,501,c0a9f8a2,c7067000,...) at panic+0x12c tcp_ctloutput(c7546c60,c6f4b744,c07f3c0a,c7546c60,0,...) at tcp_ctloutput+0x5e sosetopt(c7546c60,c6f4b744,1,0,c73b6400,...) at sosetopt+0x3d nfs_connect(c7467000,c7670000,c0b20436,21d,c7670044,...) at nfs_connect+0x1b9 nfs_reconnect(c7670044,0,c0b20436,2e2,0,...) at nfs_reconnect+0x15e nfs_request(c725bb84,c7379400,4,c74f5d20,c7547900,...) at nfs_request+0x6c3 nfs3_access_otw(c7547900,0,c0b20ac9,180,0,...) at nfs3_access_otw+0xde nfs_access(c6f4b9cc,c6f4b9b4,c077bed7,c74f5d20,c6f4ba18,...) at nfs_access+0x15e VOP_ACCESS_APV(c0bf16a0,c6f4b9cc,c6f4b954,0,c6f4b95c,...) at VOP_ACCESS_APV+0xa5 nfs_lookup(c6f4ba78,c6f4ba78,5000044,80000,c725bb84,...) at nfs_lookup+0xcb VOP_LOOKUP_APV(c0bf16a0,c6f4ba78,c0b0fd3c,1b0,c6f4bb9c,...) at VOP_LOOKUP_APV+0xa5 lookup(c6f4bb84,c0b0fd3c,d8,c0,c7547e2c,...) at lookup+0x57e namei(c6f4bb84,c6f4bb24,60,0,c74f5d20,...) at namei+0x44b kern_statat(c74f5d20,0,ffffff9c,804ec77,0,...) at kern_statat+0x64 kern_stat(c74f5d20,804ec77,0,c6f4bc18,6b,...) at kern_stat+0x36 stat(c74f5d20,c6f4bcf8,8,c0b0a981,c0bd7400,...) at stat+0x2f syscall(c6f4bd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x28163c6b, esp = 0xbfbfea3c, ebp = 0xbfbfed38 --- /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From bz at FreeBSD.org Sun Aug 24 18:50:07 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sun Aug 24 18:50:13 2008 Subject: ``vimage'' Step 1.5 and following schedule Message-ID: <20080824183430.C66593@maildrop.int.zabbadoz.net> Hi, in addition to the commit dates on http://wiki.freebsd.org/Image/Notes200808DevSummit I am trying to coordinate other things. Ideally after Step 1.5 (if that does not work out) after Step 2, multi-IP jail work should go in. This will help Jamie to prepare a commit for the management interface itself (no hierachies, no vnet support yet) in parallel to Step 2/3 and get that in, reduce his diff, get help with review, ... The deadline for Step 1.5 commit is set as Sep 1st (tomorrow and a week) and we should consider that reviewers will need their time as well. Marko, Julian, in case you need help (as life/works/.. keeps you busy) to get the INIT_VNET_*, etc. changes into vimage-commit2 let me know and I will find someone else to do it/help. Just let me know. I just would prefer to stay close to the schedule for those "easy" (style) parts. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From baigsabeeh at gmail.com Sun Aug 24 19:04:46 2008 From: baigsabeeh at gmail.com (Sabeeh Baig) Date: Sun Aug 24 19:04:53 2008 Subject: Xen Status Message-ID: Going back to Xen, if work has just begun on DomU support for inclusion in FreeBSD 8.0R with the aim of eventually implementing Dom0 support, I'm assuming that Dom0 will not be ready for 8.0R, right? -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Sabeeh Ahmed Baig From kmacy at freebsd.org Sun Aug 24 19:20:45 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sun Aug 24 19:20:51 2008 Subject: Xen Status In-Reply-To: References: Message-ID: <3c1674c90808241220j547efbe5n3ea9891b6de37fb1@mail.gmail.com> On Sun, Aug 24, 2008 at 12:04 PM, Sabeeh Baig wrote: > Going back to Xen, if work has just begun on DomU support for > inclusion in FreeBSD 8.0R with the aim of eventually implementing Dom0 > support, I'm assuming that Dom0 will not be ready for 8.0R, right? The freeze date for 8.0 has not been announced yet. It is still possible that it will have dom0 support. However, I'm not making any promises to that effect at this time. -Kip > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to understand the simplicity." > > Sabeeh Ahmed Baig > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > From julian at elischer.org Sun Aug 24 19:33:39 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Aug 24 19:33:45 2008 Subject: ``vimage'' Step 1.5 and following schedule In-Reply-To: <20080824183430.C66593@maildrop.int.zabbadoz.net> References: <20080824183430.C66593@maildrop.int.zabbadoz.net> Message-ID: <48B1B791.6000702@elischer.org> Bjoern A. Zeeb wrote: > Hi, > > in addition to the commit dates on > http://wiki.freebsd.org/Image/Notes200808DevSummit > I am trying to coordinate other things. > > Ideally after Step 1.5 (if that does not work out) after Step 2, > multi-IP jail work should go in. > > This will help Jamie to prepare a commit for the management interface > itself (no hierachies, no vnet support yet) in parallel to Step 2/3 > and get that in, reduce his diff, get help with review, ... > > > The deadline for Step 1.5 commit is set as Sep 1st (tomorrow and a week) > and we should consider that reviewers will need their time as well. > > Marko, Julian, in case you need help (as life/works/.. keeps you busy) > to get the INIT_VNET_*, etc. changes into vimage-commit2 let me know and > I will find someone else to do it/help. Just let me know. > > I just would prefer to stay close to the schedule for those "easy" > (style) parts. > > /bz > hi the vimage branch is currently broken after the big merge.. LINT compiles fine (i.e. no-vimage works) but there is a problem in kern_vimage.c that I haven't reso0lved yet that stops a VIMAGE kernel from compiling.. I should have a couple of hours today to try sort it out.. then my next aim is to generate a merged vimage-commit3 and vimage-commit1 branch (i.e. merge all the changes into vimage-commit2 which is our our real commit branch) and that would be the candidate for the next commit. I'll see how much I can get done today. From julian at elischer.org Mon Aug 25 08:03:06 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Aug 25 08:03:13 2008 Subject: progress toward next commit. Message-ID: <48B26739.1080504@elischer.org> As those of you who have been following will know, the next commit should be a bunch of macros that don't actually do anything without VIMAGE defined but clutter up the diff tremendously. I had 2 branches that were used to generate this diff and I have now moved all the changes from them to the branch "vimage-commit2" (our commit staging area). The branches "vimage-commit" and "vimage-commit3" should be considered dead for now.. I will remmove them as soon as I can. the branch vimage-commit2 contains my current candidate for commit. It has not been verified or reviewed by anyone else yet and I'm still working on it, so I expect changes. to view the diffs against -current look at: http://www.freebsd.org/~julian/commit2.diff to view the remaining diffs required to get to a working vimage system see: http://www.freebsd.org/~julian/meat.diff These can be generated in the base of the vimage-commit2 branch by the perl scripts makediff.pl and makemeat.pl respectively. The meat diff shows what the vimage patch looks like after all these 'clutter' changes have been removed, leaving the 'meat' of the diff. i.e. things that are really interesting, and need review. I have some cleaning up to do still as for example the contents of vnetgraph.h can also be found in netgraph.h. One of them should go away. similar things can be found elsewhere, but it's late and I need to go to bed... :-) (also marko, it looks as if there is still some vcpu in vimage branch.. look in the 'meat' diff.) regards Julian. From julian at ironport.com Mon Aug 25 08:23:50 2008 From: julian at ironport.com (Julian Elischer) Date: Mon Aug 25 08:27:45 2008 Subject: progress toward next commit. Message-ID: <48B26560.4090303@ironport.com> As those of you who have been following will know, the next commit should be a bunch of macros that don't actually do anything without VIMAGE defined but clutter up the diff tremendously. I had 2 branches that were used to generate this diff and I have now moved all the changes from them to the branch "vimage-commit2" (our commit staging area). The branches "vimage-commit" and "vimage-commit3" should be considered dead for now.. I will remmove them as soon as I can. the branch vimage-commit2 contains my current candidate for commit. It has not been verified or reviewed by anyone else yet and I'm still working on it, so I expect changes. to view the diffs against -current look at: http://www.freebsd.org/~julian/commit2.diff to view the remaining diffs required to get to a working vimage system see: http://www.freebsd.org/~julian/meat.diff These can be generated in the base of the vimage-commit2 branch by the perl scripts makediff.pl and makemeat.pl respectively. The meat diff shows what the vimage patch looks like after all these 'clutter' changes have been removed, leaving the 'meat' of the diff. i.e. things that are really interesting, and need review. I have some cleaning up to do still as for example the contents of vnetgraph.h can also be found in netgraph.h. One of them should go away. similar things can be found elsewhere, but it's late and I need to go to bed... :-) regards Julian. From jamie at gritton.org Tue Aug 26 23:28:28 2008 From: jamie at gritton.org (James Gritton) Date: Tue Aug 26 23:29:28 2008 Subject: panic in vimage/jamie_jail_set In-Reply-To: <20080824141835.K66593@maildrop.int.zabbadoz.net> References: <20080824141835.K66593@maildrop.int.zabbadoz.net> Message-ID: <48B48BFD.4050108@gritton.org> I haven't seen the panic you describe, but on a jail_set_vimage integrated from the latest vimage code, I get a similar idle network panic. This happens in tcp_hc_purge(), which clearly expected a struct vnet pointer as its argument, but is only ever called with NULL. It seems reasonable to pass tcp_hc_init's curvnet as the argument, but I don't know if there are referencing issues. - Jamie Bjoern A. Zeeb wrote: > Hi, > > I had a jamie_jail_set kernel running from > db> x/s version > version: FreeBSD 8.0-CURRENT #0: Fri Aug 15 10:01:11 UTC 2008 ... > > and it paniced while standing idle. I am not sure if that had been > fixed in the vimage branch but not integrated into jamie_jail_set or > if this was a different issue to what kris had seen? > > Unfortunately the console hasn't been to reliable, so this is what I > have: > > panic: in ../../../netinet/tcp_usrreq.c:1281 tcp_ctloutput()^M^@ > vnet=0xc7067000 curvnet=0^M^@ > cpuid = 0^M^@ > KDB: enter: panic^M^@ > [thread pid 852 tid 100051 ]^M^@ > Stopped at kdb_enter+0x3a: movl $0,kdb_why^M^@ > > Tracing pid 852 tid 100051 td 0xc74f5d20 > kdb_enter(c0b04531,c0b04531,c0b05c88,c6f4b59c,0,...) at kdb_enter+0x3a > panic(c0b05c88,c0b1cb7f,501,c0a9f8a2,c7067000,...) at panic+0x12c > tcp_ctloutput(c7546c60,c6f4b744,c07f3c0a,c7546c60,0,...) at > tcp_ctloutput+0x5e > sosetopt(c7546c60,c6f4b744,1,0,c73b6400,...) at sosetopt+0x3d > nfs_connect(c7467000,c7670000,c0b20436,21d,c7670044,...) at > nfs_connect+0x1b9 > nfs_reconnect(c7670044,0,c0b20436,2e2,0,...) at nfs_reconnect+0x15e > nfs_request(c725bb84,c7379400,4,c74f5d20,c7547900,...) at > nfs_request+0x6c3 > nfs3_access_otw(c7547900,0,c0b20ac9,180,0,...) at nfs3_access_otw+0xde > nfs_access(c6f4b9cc,c6f4b9b4,c077bed7,c74f5d20,c6f4ba18,...) at > nfs_access+0x15e > VOP_ACCESS_APV(c0bf16a0,c6f4b9cc,c6f4b954,0,c6f4b95c,...) at > VOP_ACCESS_APV+0xa5 > nfs_lookup(c6f4ba78,c6f4ba78,5000044,80000,c725bb84,...) at > nfs_lookup+0xcb > VOP_LOOKUP_APV(c0bf16a0,c6f4ba78,c0b0fd3c,1b0,c6f4bb9c,...) at > VOP_LOOKUP_APV+0xa5 > lookup(c6f4bb84,c0b0fd3c,d8,c0,c7547e2c,...) at lookup+0x57e > namei(c6f4bb84,c6f4bb24,60,0,c74f5d20,...) at namei+0x44b > kern_statat(c74f5d20,0,ffffff9c,804ec77,0,...) at kern_statat+0x64 > kern_stat(c74f5d20,804ec77,0,c6f4bc18,6b,...) at kern_stat+0x36 > stat(c74f5d20,c6f4bcf8,8,c0b0a981,c0bd7400,...) at stat+0x2f > syscall(c6f4bd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (188, FreeBSD ELF32, stat), eip = 0x28163c6b, esp = > 0xbfbfea3c, ebp = 0xbfbfed38 --- > > /bz > From julian at elischer.org Tue Aug 26 23:40:36 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 26 23:40:44 2008 Subject: panic in vimage/jamie_jail_set In-Reply-To: <48B48BFD.4050108@gritton.org> References: <20080824141835.K66593@maildrop.int.zabbadoz.net> <48B48BFD.4050108@gritton.org> Message-ID: <48B49478.4020203@elischer.org> James Gritton wrote: > I haven't seen the panic you describe, but on a jail_set_vimage > integrated from the latest vimage code, I get a similar idle network panic. > > This happens in tcp_hc_purge(), which clearly expected a struct vnet > pointer as its argument, but is only ever called with NULL. It seems > reasonable to pass tcp_hc_init's curvnet as the argument, but I don't > know if there are referencing issues. I've made a change that fixes a mismerge where teh callout_reset was called and told to call tcp_hc_purge with a null instead of the current vnet. Bjoern, see if that helps.. (just tcp_hostcache.c needs fixing) > > - Jamie > > > Bjoern A. Zeeb wrote: >> Hi, >> >> I had a jamie_jail_set kernel running from >> db> x/s version >> version: FreeBSD 8.0-CURRENT #0: Fri Aug 15 10:01:11 UTC 2008 ... >> >> and it paniced while standing idle. I am not sure if that had been >> fixed in the vimage branch but not integrated into jamie_jail_set or >> if this was a different issue to what kris had seen? >> >> Unfortunately the console hasn't been to reliable, so this is what I >> have: >> >> panic: in ../../../netinet/tcp_usrreq.c:1281 tcp_ctloutput()^M^@ >> vnet=0xc7067000 curvnet=0^M^@ >> cpuid = 0^M^@ >> KDB: enter: panic^M^@ >> [thread pid 852 tid 100051 ]^M^@ >> Stopped at kdb_enter+0x3a: movl $0,kdb_why^M^@ >> >> Tracing pid 852 tid 100051 td 0xc74f5d20 >> kdb_enter(c0b04531,c0b04531,c0b05c88,c6f4b59c,0,...) at kdb_enter+0x3a >> panic(c0b05c88,c0b1cb7f,501,c0a9f8a2,c7067000,...) at panic+0x12c >> tcp_ctloutput(c7546c60,c6f4b744,c07f3c0a,c7546c60,0,...) at >> tcp_ctloutput+0x5e >> sosetopt(c7546c60,c6f4b744,1,0,c73b6400,...) at sosetopt+0x3d >> nfs_connect(c7467000,c7670000,c0b20436,21d,c7670044,...) at >> nfs_connect+0x1b9 >> nfs_reconnect(c7670044,0,c0b20436,2e2,0,...) at nfs_reconnect+0x15e >> nfs_request(c725bb84,c7379400,4,c74f5d20,c7547900,...) at >> nfs_request+0x6c3 >> nfs3_access_otw(c7547900,0,c0b20ac9,180,0,...) at nfs3_access_otw+0xde >> nfs_access(c6f4b9cc,c6f4b9b4,c077bed7,c74f5d20,c6f4ba18,...) at >> nfs_access+0x15e >> VOP_ACCESS_APV(c0bf16a0,c6f4b9cc,c6f4b954,0,c6f4b95c,...) at >> VOP_ACCESS_APV+0xa5 >> nfs_lookup(c6f4ba78,c6f4ba78,5000044,80000,c725bb84,...) at >> nfs_lookup+0xcb >> VOP_LOOKUP_APV(c0bf16a0,c6f4ba78,c0b0fd3c,1b0,c6f4bb9c,...) at >> VOP_LOOKUP_APV+0xa5 >> lookup(c6f4bb84,c0b0fd3c,d8,c0,c7547e2c,...) at lookup+0x57e >> namei(c6f4bb84,c6f4bb24,60,0,c74f5d20,...) at namei+0x44b >> kern_statat(c74f5d20,0,ffffff9c,804ec77,0,...) at kern_statat+0x64 >> kern_stat(c74f5d20,804ec77,0,c6f4bc18,6b,...) at kern_stat+0x36 >> stat(c74f5d20,c6f4bcf8,8,c0b0a981,c0bd7400,...) at stat+0x2f >> syscall(c6f4bd38) at syscall+0x2a3 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (188, FreeBSD ELF32, stat), eip = 0x28163c6b, esp = >> 0xbfbfea3c, ebp = 0xbfbfed38 --- >> >> /bz >> > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From julian at elischer.org Tue Aug 26 23:44:40 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Aug 26 23:44:47 2008 Subject: panic in vimage/jamie_jail_set In-Reply-To: <48B49478.4020203@elischer.org> References: <20080824141835.K66593@maildrop.int.zabbadoz.net> <48B48BFD.4050108@gritton.org> <48B49478.4020203@elischer.org> Message-ID: <48B4956B.40704@elischer.org> Julian Elischer wrote: > James Gritton wrote: >> I haven't seen the panic you describe, but on a jail_set_vimage >> integrated from the latest vimage code, I get a similar idle network >> panic. >> >> This happens in tcp_hc_purge(), which clearly expected a struct vnet >> pointer as its argument, but is only ever called with NULL. It seems >> reasonable to pass tcp_hc_init's curvnet as the argument, but I don't >> know if there are referencing issues. (btw curvnet was what was there before the mismerge) > > I've made a change that fixes a mismerge > where teh callout_reset was called and told to call tcp_hc_purge with a > null instead of the current vnet. > > Bjoern, see if that helps.. (just tcp_hostcache.c needs fixing) > > >> - Jamie >> >> >> Bjoern A. Zeeb wrote: >>> Hi, >>> >>> I had a jamie_jail_set kernel running from >>> db> x/s version >>> version: FreeBSD 8.0-CURRENT #0: Fri Aug 15 10:01:11 UTC 2008 ... >>> >>> and it paniced while standing idle. I am not sure if that had been >>> fixed in the vimage branch but not integrated into jamie_jail_set or >>> if this was a different issue to what kris had seen? >>> >>> Unfortunately the console hasn't been to reliable, so this is what I >>> have: >>> >>> panic: in ../../../netinet/tcp_usrreq.c:1281 tcp_ctloutput()^M^@ >>> vnet=0xc7067000 curvnet=0^M^@ >>> cpuid = 0^M^@ >>> KDB: enter: panic^M^@ >>> [thread pid 852 tid 100051 ]^M^@ >>> Stopped at kdb_enter+0x3a: movl $0,kdb_why^M^@ >>> >>> Tracing pid 852 tid 100051 td 0xc74f5d20 >>> kdb_enter(c0b04531,c0b04531,c0b05c88,c6f4b59c,0,...) at kdb_enter+0x3a >>> panic(c0b05c88,c0b1cb7f,501,c0a9f8a2,c7067000,...) at panic+0x12c >>> tcp_ctloutput(c7546c60,c6f4b744,c07f3c0a,c7546c60,0,...) at >>> tcp_ctloutput+0x5e >>> sosetopt(c7546c60,c6f4b744,1,0,c73b6400,...) at sosetopt+0x3d >>> nfs_connect(c7467000,c7670000,c0b20436,21d,c7670044,...) at >>> nfs_connect+0x1b9 >>> nfs_reconnect(c7670044,0,c0b20436,2e2,0,...) at nfs_reconnect+0x15e >>> nfs_request(c725bb84,c7379400,4,c74f5d20,c7547900,...) at >>> nfs_request+0x6c3 >>> nfs3_access_otw(c7547900,0,c0b20ac9,180,0,...) at nfs3_access_otw+0xde >>> nfs_access(c6f4b9cc,c6f4b9b4,c077bed7,c74f5d20,c6f4ba18,...) at >>> nfs_access+0x15e >>> VOP_ACCESS_APV(c0bf16a0,c6f4b9cc,c6f4b954,0,c6f4b95c,...) at >>> VOP_ACCESS_APV+0xa5 >>> nfs_lookup(c6f4ba78,c6f4ba78,5000044,80000,c725bb84,...) at >>> nfs_lookup+0xcb >>> VOP_LOOKUP_APV(c0bf16a0,c6f4ba78,c0b0fd3c,1b0,c6f4bb9c,...) at >>> VOP_LOOKUP_APV+0xa5 >>> lookup(c6f4bb84,c0b0fd3c,d8,c0,c7547e2c,...) at lookup+0x57e >>> namei(c6f4bb84,c6f4bb24,60,0,c74f5d20,...) at namei+0x44b >>> kern_statat(c74f5d20,0,ffffff9c,804ec77,0,...) at kern_statat+0x64 >>> kern_stat(c74f5d20,804ec77,0,c6f4bc18,6b,...) at kern_stat+0x36 >>> stat(c74f5d20,c6f4bcf8,8,c0b0a981,c0bd7400,...) at stat+0x2f >>> syscall(c6f4bd38) at syscall+0x2a3 >>> Xint0x80_syscall() at Xint0x80_syscall+0x20 >>> --- syscall (188, FreeBSD ELF32, stat), eip = 0x28163c6b, esp = >>> 0xbfbfea3c, ebp = 0xbfbfed38 --- >>> >>> /bz >>> >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From bz at FreeBSD.org Wed Aug 27 17:25:08 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Wed Aug 27 17:25:16 2008 Subject: progress toward next commit. In-Reply-To: <48B26560.4090303@ironport.com> References: <48B26560.4090303@ironport.com> Message-ID: <20080827171910.A66593@maildrop.int.zabbadoz.net> On Mon, 25 Aug 2008, Julian Elischer wrote: Hi, > the branch vimage-commit2 contains my current candidate for commit. > It has not been verified or reviewed by anyone else yet > and I'm still working on it, so I expect changes. Can you let us know once you are 'done' (try to leave something for the reviewers as well;-))? Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From julian at elischer.org Wed Aug 27 18:17:06 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Aug 27 18:17:13 2008 Subject: progress toward next commit. In-Reply-To: <20080827171910.A66593@maildrop.int.zabbadoz.net> References: <48B26560.4090303@ironport.com> <20080827171910.A66593@maildrop.int.zabbadoz.net> Message-ID: <48B59A26.7020907@elischer.org> Bjoern A. Zeeb wrote: > On Mon, 25 Aug 2008, Julian Elischer wrote: > > Hi, > >> the branch vimage-commit2 contains my current candidate for commit. >> It has not been verified or reviewed by anyone else yet >> and I'm still working on it, so I expect changes. > > Can you let us know once you are 'done' (try to leave something for > the reviewers as well;-))? feel free to help :-) part of this commit is the adding of the actual vimage .h files and definitions... e.g. vinet.h and vnet.h, vinet6.h The definitions in these files could go in in.h in6.h and other places but there is some aesthetic reason for keeping them separate, and having them included at the end of each of those files as required.. currently I have: in.h includes vinet.h ip6.h includes vinet6.h and if.h includes vnet.h I chose these because it turns out that these files are already included in 98% of all teh files that need to iclude the vxxx.h files. so the actual .c files themselves don't need to include them To make this work I had to add #include if.h to exactly 3 files.. On further consideration I migh change those 3 files to just include directly without polluting themselves with if.h. While this adds a lot of vimage stuff that is not yet active, I feel it is better to get the files in now and shrink the remaining diff, and it still results in 0 actual code changes. > > Regards, > Bjoern > From julian at ironport.com Wed Aug 27 18:43:38 2008 From: julian at ironport.com (Julian Elischer) Date: Wed Aug 27 18:47:00 2008 Subject: progress toward next commit. In-Reply-To: <20080827171910.A66593@maildrop.int.zabbadoz.net> References: <48B26560.4090303@ironport.com> <20080827171910.A66593@maildrop.int.zabbadoz.net> Message-ID: <48B599AC.4020401@ironport.com> Bjoern A. Zeeb wrote: > On Mon, 25 Aug 2008, Julian Elischer wrote: > > Hi, > >> the branch vimage-commit2 contains my current candidate for commit. >> It has not been verified or reviewed by anyone else yet >> and I'm still working on it, so I expect changes. > > Can you let us know once you are 'done' (try to leave something for > the reviewers as well;-))? feel free to help :-) part of this commit is the adding of the actual vimage .h files and definitions... e.g. vinet.h and vnet.h, vinet6.h The definitions in these files could go in in.h in6.h and other places but there is some aesthetic reason for keeping them separate, and having them included at the end of each of those files as required.. currently I have: in.h includes vinet.h ip6.h includes vinet6.h and if.h includes vnet.h I chose these because it turns out that these files are already included in 98% of all teh files that need to iclude the vxxx.h files. so the actual .c files themselves don't need to include them To make this work I had to add #include if.h to exactly 3 files.. On further consideration I migh change those 3 files to just include directly without polluting themselves with if.h. While this adds a lot of vimage stuff that is not yet active, I feel it is better to get the files in now and shrink the remaining diff, and it still results in 0 actual code changes. > > Regards, > Bjoern > From bz at FreeBSD.org Thu Aug 28 21:40:13 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Thu Aug 28 21:40:20 2008 Subject: Step 1.5 needs review Message-ID: <20080828185639.P66593@maildrop.int.zabbadoz.net> Hi, in case you are interested or have volunteered before to review Step 1.5 as described on http://wiki.freebsd.org/Image/Notes200808DevSummit there are few things to do: - review the diff (Julian posted an initial one). - make sure all (relevant) sysctl were caught. - make sure the INIT_VNET_* macro is there whereever it is needed. - do builds according to "HOWTO verify that the pure style changes are all right" on the above mentioned page and verify that it is all style changes. In case there are others we shoudl decide to either commit them either upfront or afterwards if possible. - the 'include headers' one way or the other (as we have discussed at the devsummit and that Julian has told me again) needs resolving. As this has bikeshed potential, I'd prefer that the 'singed up' reviewers decide that. - possibly more... The plan would be to have a final patch by Monday morning UTC to be comitted by a volunteer. Regards, Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From Daniel.Schwager at dtnet.de Sun Aug 31 12:16:53 2008 From: Daniel.Schwager at dtnet.de (Daniel Schwager) Date: Sun Aug 31 12:16:59 2008 Subject: live & onlinedemo with freebsd 7.0 ? Message-ID: Hi all, we operate the platform softwaredemo.com and want to publish many open source OS like OpenSuSE11, debian, ubuntu, opensolaris, ... online and live for the communities. Is somebody is interesting to run a live system of freebsd on softwaredemo.de ? If so, please create a HVM-Xen-DomU (HVM !) image of freebsd with - available Resources - 1CPU, 512MB RAM - setup - one HDD with about 8 GB - DHCP-configuration, one NIC - progs - telnetd and sshd, xauth - X11-base progs (xterm, xclock, ..) - nice packages/programs you will show to other people - a windowmanger (gnome, kde, ... ??) - accounts - an account "jgast" with sudo-right's, password "secret" - root account, password "secret" This image should run on a i386-Fedora-Core8 Dom0 on Xen 3.2.1. Regards Danny from softwaredemo.de