From brooks at freebsd.org Tue Sep 2 00:24:00 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Sep 2 00:24:07 2008 Subject: Step 1.5 needs review In-Reply-To: <20080828185639.P66593@maildrop.int.zabbadoz.net> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> Message-ID: <20080902000516.GA48622@lor.one-eyed-alien.net> On Thu, Aug 28, 2008 at 07:03:30PM +0000, Bjoern A. Zeeb wrote: > 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. I've gone over the patch and fixed some white space issues. I've also found some things I'm not sure what to do with. Comments: - GENERIC_NODEBUG should not be committed - VNET_ITERLOOP_BEGIN/END is evil. It would be really nice to find a way to do this that preserves {} pairs and isn't too magic. - sys/kern/tty.c: - There's some #if 0 code that presumably should stay in the vimage branch for now and be fixed before the final commit. - TIOCDRAIN is being removed. Is this a merge issue or something else? - sys/net/if.h: - shouldn't net/vnet.h be included in if_var.h instead? *_var.h is supposed to be the internals and I think this qualifies. If so, there will be a number of files that added if.h includes that should add if_var.h includes instead. - sys/netinet/ip_fw.h: - It's not clear to me that all the changes in this file should actually be here. It looks like there may be some merge issues or WIP code. - sys/netinet6/icmp6.c: - This (and IIRC a couple other files in ipsec) contain comments like "XXX this below is WRONG". It would be nice if the issue could be fixed or if that's not feasible, a more detailed comment should be added. - sys/netipsec/ipsec.c: - This and a few other files change the style of SYSCTL*() macro usage. We're not at all consistent across the kernel, but my feeling is that we should either entirely preserve the local style or we should figure out what the style should be and do the churn now while we have to mangle the wrapping anyway. Also, we're due for another integrate round soon. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080902/ad30adfa/attachment.pgp From julian at elischer.org Tue Sep 2 07:38:49 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 2 07:38:55 2008 Subject: Step 1.5 needs review In-Reply-To: <20080902000516.GA48622@lor.one-eyed-alien.net> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> Message-ID: <48BCED8E.5030109@elischer.org> Brooks Davis wrote: > On Thu, Aug 28, 2008 at 07:03:30PM +0000, Bjoern A. Zeeb wrote: >> 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. > > I've gone over the patch and fixed some white space issues. I've also > found some things I'm not sure what to do with. Comments: > > - GENERIC_NODEBUG should not be committed > - VNET_ITERLOOP_BEGIN/END is evil. It would be really nice to find a > way to do this that preserves {} pairs and isn't too magic. The requirement is to take soem code that doesn something once. and do it once for each vimage. There are of course many ways to do this.. Once we have the code in, I think we should expand this out and correctly indent the code, but for reasons of "minimum diff size" teh current way seems ok to me though it doens't look pretty.. I suggest that we eventually replace: VNET_ITERLOOP_BEGIN stuff VNET_ITERLOOP_END with (eventually) FOREACH_VNET(vnet) { stuff } but that would require that the entire contents of "stuff" would appear in the diff. > - sys/kern/tty.c: > - There's some #if 0 code that presumably should stay in the vimage > branch for now and be fixed before the final commit. > - TIOCDRAIN is being removed. Is this a merge issue or something > else? not sure myself.. I've been only following the tty mashup from a distance. > - sys/net/if.h: > - shouldn't net/vnet.h be included in if_var.h instead? *_var.h is > supposed to be the internals and I think this qualifies. If so, > there will be a number of files that added if.h includes that > should add if_var.h includes instead. I actually looked around to find a good place to icnlude vnet.h from and decided on if.h because it seemt o be included almist everywhere that vnet.h needed to be included, but I'm not religious on it. teh original code actually includes vnet.h directly in about 50 source files. my attempt to include it from if.h cut that down to 3. I'm not sure I want to actually include the contents directly into if.h or any other place.. I think keeping a separate vnet.h and vinet.h seems ok to me. > - sys/netinet/ip_fw.h: > - It's not clear to me that all the changes in this file should > actually be here. It looks like there may be some merge issues or > WIP code. I'll have a look. thanks for the pointer. > - sys/netinet6/icmp6.c: > - This (and IIRC a couple other files in ipsec) contain comments like > "XXX this below is WRONG". It would be nice if the issue could be > fixed or if that's not feasible, a more detailed comment should > be added. hmm yeah > - sys/netipsec/ipsec.c: > - This and a few other files change the style of SYSCTL*() macro > usage. We're not at all consistent across the kernel, but my > feeling is that we should either entirely preserve the local style > or we should figure out what the style should be and do the churn > now while we have to mangle the wrapping anyway. > I can do that (or you can... just run the update.sh script at the base..) > > -- Brooks From jamie at gritton.org Tue Sep 2 13:26:57 2008 From: jamie at gritton.org (James Gritton) Date: Tue Sep 2 13:27:17 2008 Subject: Step 1.5 needs review In-Reply-To: <48BCED8E.5030109@elischer.org> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> Message-ID: <48BD3F1C.9050202@gritton.org> These are related to the virtual hostname stubs in vimage, all of which will be fixed when the jail_set framework is added. - Jamie Julian Elischer wrote: > Brooks Davis wrote: > >> - sys/netinet6/icmp6.c: >> - This (and IIRC a couple other files in ipsec) contain comments like >> "XXX this below is WRONG". It would be nice if the issue could be >> fixed or if that's not feasible, a more detailed comment should >> be added. > > hmm yeah From brooks at freebsd.org Tue Sep 2 14:12:10 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Sep 2 14:12:16 2008 Subject: Step 1.5 needs review In-Reply-To: <48BCED8E.5030109@elischer.org> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> Message-ID: <20080902141245.GB48622@lor.one-eyed-alien.net> On Tue, Sep 02, 2008 at 12:38:54AM -0700, Julian Elischer wrote: > Brooks Davis wrote: >> On Thu, Aug 28, 2008 at 07:03:30PM +0000, Bjoern A. Zeeb wrote: >>> 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. >> >> I've gone over the patch and fixed some white space issues. I've also >> found some things I'm not sure what to do with. Comments: >> >> - GENERIC_NODEBUG should not be committed >> - VNET_ITERLOOP_BEGIN/END is evil. It would be really nice to find a >> way to do this that preserves {} pairs and isn't too magic. > > The requirement is to take soem code that doesn something once. > and do it once for each vimage. There are of course many ways to do this.. > > Once we have the code in, I think we should expand this out > and correctly indent the code, but for reasons of "minimum diff size" > teh current way seems ok to me though it doens't look pretty.. > > I suggest that we eventually replace: > > VNET_ITERLOOP_BEGIN > stuff > VNET_ITERLOOP_END > > > with (eventually) > > FOREACH_VNET(vnet) { > stuff > } > > but that would require that the entire contents of "stuff" > would appear in the diff. Thinking about it more, at a minimum, I think we should do: VNET_ITERLOOP_BEGIN stuff VNET_ITERLOOP_END >> - sys/kern/tty.c: >> - There's some #if 0 code that presumably should stay in the vimage >> branch for now and be fixed before the final commit. >> - TIOCDRAIN is being removed. Is this a merge issue or something >> else? > > > not sure myself.. I've been only following the tty mashup from a distance. > >> - sys/net/if.h: >> - shouldn't net/vnet.h be included in if_var.h instead? *_var.h is >> supposed to be the internals and I think this qualifies. If so, >> there will be a number of files that added if.h includes that >> should add if_var.h includes instead. > > I actually looked around to find a good place to icnlude vnet.h from > and decided on if.h because it seemt o be included almist everywhere > that vnet.h needed to be included, but I'm not religious on it. > > teh original code actually includes vnet.h directly in about 50 source > files. > > my attempt to include it from if.h cut that down to 3. > > I'm not sure I want to actually include the contents directly into > if.h or any other place.. I think keeping a separate vnet.h and > vinet.h seems ok to me. The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if it's going to be included in another header (IMO, the vnet/vinet.h files aren't a good idea in the long term). -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080902/9c53ca64/attachment.pgp From julian at elischer.org Tue Sep 2 14:33:29 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Sep 2 14:33:35 2008 Subject: Step 1.5 needs review In-Reply-To: <20080902141245.GB48622@lor.one-eyed-alien.net> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> Message-ID: <48BD4EBE.4010005@elischer.org> Brooks Davis wrote: > On Tue, Sep 02, 2008 at 12:38:54AM -0700, Julian Elischer wrote: >> Brooks Davis wrote: >>> On Thu, Aug 28, 2008 at 07:03:30PM +0000, Bjoern A. Zeeb wrote: >>>> 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. >>> I've gone over the patch and fixed some white space issues. I've also >>> found some things I'm not sure what to do with. Comments: >>> >>> - GENERIC_NODEBUG should not be committed >>> - VNET_ITERLOOP_BEGIN/END is evil. It would be really nice to find a >>> way to do this that preserves {} pairs and isn't too magic. >> The requirement is to take soem code that doesn something once. >> and do it once for each vimage. There are of course many ways to do this.. >> >> Once we have the code in, I think we should expand this out >> and correctly indent the code, but for reasons of "minimum diff size" >> teh current way seems ok to me though it doens't look pretty.. >> >> I suggest that we eventually replace: >> >> VNET_ITERLOOP_BEGIN >> stuff >> VNET_ITERLOOP_END >> >> >> with (eventually) >> >> FOREACH_VNET(vnet) { >> stuff >> } >> >> but that would require that the entire contents of "stuff" >> would appear in the diff. > > Thinking about it more, at a minimum, I think we should do: > VNET_ITERLOOP_BEGIN > stuff > VNET_ITERLOOP_END when? (i.e. at which stage)? and doing FOREACH_VNET() {} will allow brace matching... > >>> - sys/kern/tty.c: >>> - There's some #if 0 code that presumably should stay in the vimage >>> branch for now and be fixed before the final commit. >>> - TIOCDRAIN is being removed. Is this a merge issue or something >>> else? >> >> not sure myself.. I've been only following the tty mashup from a distance. >> >>> - sys/net/if.h: >>> - shouldn't net/vnet.h be included in if_var.h instead? *_var.h is >>> supposed to be the internals and I think this qualifies. If so, >>> there will be a number of files that added if.h includes that >>> should add if_var.h includes instead. >> I actually looked around to find a good place to icnlude vnet.h from >> and decided on if.h because it seemt o be included almist everywhere >> that vnet.h needed to be included, but I'm not religious on it. >> >> teh original code actually includes vnet.h directly in about 50 source >> files. >> >> my attempt to include it from if.h cut that down to 3. >> >> I'm not sure I want to actually include the contents directly into >> if.h or any other place.. I think keeping a separate vnet.h and >> vinet.h seems ok to me. > > The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if it's > going to be included in another header (IMO, the vnet/vinet.h files > aren't a good idea in the long term). > > -- Brooks From brooks at freebsd.org Tue Sep 2 14:44:14 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Sep 2 14:44:25 2008 Subject: Step 1.5 needs review In-Reply-To: <48BD4EBE.4010005@elischer.org> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> <48BD4EBE.4010005@elischer.org> Message-ID: <20080902144450.GC48622@lor.one-eyed-alien.net> On Tue, Sep 02, 2008 at 07:33:34AM -0700, Julian Elischer wrote: > Brooks Davis wrote: >> On Tue, Sep 02, 2008 at 12:38:54AM -0700, Julian Elischer wrote: >>> Brooks Davis wrote: >>>> On Thu, Aug 28, 2008 at 07:03:30PM +0000, Bjoern A. Zeeb wrote: >>>>> 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. >>>> I've gone over the patch and fixed some white space issues. I've also >>>> found some things I'm not sure what to do with. Comments: >>>> >>>> - GENERIC_NODEBUG should not be committed >>>> - VNET_ITERLOOP_BEGIN/END is evil. It would be really nice to find a >>>> way to do this that preserves {} pairs and isn't too magic. >>> The requirement is to take soem code that doesn something once. >>> and do it once for each vimage. There are of course many ways to do this.. >>> >>> Once we have the code in, I think we should expand this out >>> and correctly indent the code, but for reasons of "minimum diff size" >>> teh current way seems ok to me though it doens't look pretty.. >>> >>> I suggest that we eventually replace: >>> >>> VNET_ITERLOOP_BEGIN >>> stuff >>> VNET_ITERLOOP_END >>> >>> >>> with (eventually) >>> >>> FOREACH_VNET(vnet) { >>> stuff >>> } >>> >>> but that would require that the entire contents of "stuff" >>> would appear in the diff. >> >> Thinking about it more, at a minimum, I think we should do: >> VNET_ITERLOOP_BEGIN >> stuff >> VNET_ITERLOOP_END > > when? (i.e. at which stage)? > > > and doing FOREACH_VNET() {} > will allow brace matching... Before the final. We probably don't need to hold this commit up for it, but we should make the commit seperate from the final one. If we could switch to FOREACH_VNET() {} soon, that would be good. -- Brooks >>>> - sys/kern/tty.c: >>>> - There's some #if 0 code that presumably should stay in the vimage >>>> branch for now and be fixed before the final commit. >>>> - TIOCDRAIN is being removed. Is this a merge issue or something >>>> else? >>> >>> not sure myself.. I've been only following the tty mashup from a distance. >>> >>>> - sys/net/if.h: >>>> - shouldn't net/vnet.h be included in if_var.h instead? *_var.h is >>>> supposed to be the internals and I think this qualifies. If so, >>>> there will be a number of files that added if.h includes that >>>> should add if_var.h includes instead. >>> I actually looked around to find a good place to icnlude vnet.h from >>> and decided on if.h because it seemt o be included almist everywhere >>> that vnet.h needed to be included, but I'm not religious on it. >>> >>> teh original code actually includes vnet.h directly in about 50 source >>> files. >>> >>> my attempt to include it from if.h cut that down to 3. >>> >>> I'm not sure I want to actually include the contents directly into >>> if.h or any other place.. I think keeping a separate vnet.h and >>> vinet.h seems ok to me. >> >> The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if it's >> going to be included in another header (IMO, the vnet/vinet.h files >> aren't a good idea in the long term). >> >> -- Brooks > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080902/2ec5c4e4/attachment.pgp From rwatson at FreeBSD.org Wed Sep 3 10:04:09 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Sep 3 10:04:22 2008 Subject: Step 1.5 needs review In-Reply-To: <20080902141245.GB48622@lor.one-eyed-alien.net> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> Message-ID: On Tue, 2 Sep 2008, Brooks Davis wrote: >> I suggest that we eventually replace: >> >> VNET_ITERLOOP_BEGIN >> stuff >> VNET_ITERLOOP_END >> >> >> with (eventually) >> >> FOREACH_VNET(vnet) { >> stuff >> } >> >> but that would require that the entire contents of "stuff" >> would appear in the diff. > > Thinking about it more, at a minimum, I think we should do: > VNET_ITERLOOP_BEGIN > stuff > VNET_ITERLOOP_END FWIW, I think we should make the change to FOREACH_VNET(vnet() { } sooner rather than later -- especially if there's no semantic change going on currently, now would be the time to do the indentation change. >> I'm not sure I want to actually include the contents directly into if.h or >> any other place.. I think keeping a separate vnet.h and vinet.h seems ok to >> me. > > The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if it's > going to be included in another header (IMO, the vnet/vinet.h files aren't a > good idea in the long term). My views on this one are a bit mixed -- if the goal is to get, in the medium term, to a case where we do explicit dereferencing rather than macros, we may find we do need more globally visible types than we had before, which may require us to have new globally included headers. That said, in.h might be as good a place as any for global inet stuff, and as long as we have piles of pointers rather than nested structs, the type issue shouldn't get too bad. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Wed Sep 3 14:26:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Sep 3 14:27:04 2008 Subject: live & onlinedemo with freebsd 7.0 ? In-Reply-To: References: Message-ID: On Sun, 31 Aug 2008, Daniel Schwager wrote: > 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. Dear Daniel: You've reached the freebsd-virtualization mailing list which is, unfortunately, not the list you're ooking for. :-) Could you instead send e-mail to core@FreeBSD.org and see if they (we) can point you in a better direction? Something to be aware of is that currently FreeBSD 7.x doesn't support Xen out of the box, although 8.x does, and 7.x will at some point. Robert N M Watson Computer Laboratory University of Cambridge > > 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 > > _______________________________________________ > 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 Wed Sep 3 16:10:34 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 3 16:10:45 2008 Subject: Step 1.5 needs review In-Reply-To: References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> Message-ID: <48BEB6FC.1070605@elischer.org> Robert Watson wrote: > > On Tue, 2 Sep 2008, Brooks Davis wrote: > >>> I suggest that we eventually replace: >>> >>> VNET_ITERLOOP_BEGIN >>> stuff >>> VNET_ITERLOOP_END >>> >>> >>> with (eventually) >>> >>> FOREACH_VNET(vnet) { >>> stuff >>> } >>> >>> but that would require that the entire contents of "stuff" >>> would appear in the diff. >> >> Thinking about it more, at a minimum, I think we should do: >> VNET_ITERLOOP_BEGIN >> stuff >> VNET_ITERLOOP_END > > FWIW, I think we should make the change to FOREACH_VNET(vnet() { } > sooner rather than later -- especially if there's no semantic change > going on currently, now would be the time to do the indentation change. > >>> I'm not sure I want to actually include the contents directly into >>> if.h or any other place.. I think keeping a separate vnet.h and >>> vinet.h seems ok to me. >> >> The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if >> it's going to be included in another header (IMO, the vnet/vinet.h >> files aren't a good idea in the long term). > > My views on this one are a bit mixed -- if the goal is to get, in the > medium term, to a case where we do explicit dereferencing rather than > macros, we may find we do need more globally visible types than we had > before, which may require us to have new globally included headers. > That said, in.h might be as good a place as any for global inet stuff, > and as long as we have piles of pointers rather than nested structs, the > type issue shouldn't get too bad. thats' where vinet is, but what about vnet.. (non inet stuff) I have it off if.h right now.. > > Robert N M Watson > Computer Laboratory > University of Cambridge From julian at elischer.org Wed Sep 3 16:31:34 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 3 16:31:44 2008 Subject: commit-2 patch refreshed Message-ID: <48BEBBEB.9090805@elischer.org> http://www.freebsd.org/~julian/commit2.diff has bee opdated to match today's current. Julian From julian at elischer.org Wed Sep 3 18:42:28 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 3 18:42:43 2008 Subject: need help from pf developer(s) In-Reply-To: References: <4863F1B0.9060603@elischer.org> <4863F509.2010408@elischer.org> <4863F5A3.9060703@elischer.org> <9a542da30806261543x667875eej8a5b6fa9da773b12@mail.gmail.com> <486443D1.40302@elischer.org> <9a542da30806270850i788fe961qcf5fe80e32519e81@mail.gmail.com> <48692C68.2030005@elischer.org> Message-ID: <48BEDA97.3030508@elischer.org> Ermal Lu?i wrote: > On Fri, Jun 27, 2008 at 3:35 AM, Julian Elischer wrote:>> The aim is that in each virtual machine we want a separate pf instance. >> >> Usually this means making all the globals in the relavent module >> be a structure element in a stucture, and accessing them via the >> V_xxx macros instead so that they can be accessed via the structure instead >> of as globals when vimage is enabled. >> >> I haven't time to give details right now but I'll get back to you with more >> details later. >> >> > Out of curiosity since this is a symbol game. > > Do static vars be handled specially to?! > > I am close to finish a patch for this but need to know how do you > handle static symbols. > ok so we are ready now... there is a document that describes what is needed: http://perforce.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt static variables hav eto be added to the structure that will be used.. the current pf changes can be seen in: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/vimage/src/sys or in http://www.freebsd.org/~julian/vimage.diff can you send me the diff that you did so far and we can discuss it? From julian at elischer.org Wed Sep 3 19:00:52 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 3 19:00:59 2008 Subject: Step 1.5 needs review In-Reply-To: <48BEB6FC.1070605@elischer.org> References: <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> <48BEB6FC.1070605@elischer.org> Message-ID: <48BEDEEA.6070602@elischer.org> Julian Elischer wrote: > Robert Watson wrote: >> >> On Tue, 2 Sep 2008, Brooks Davis wrote: >> >>>> I suggest that we eventually replace: >>>> >>>> VNET_ITERLOOP_BEGIN >>>> stuff >>>> VNET_ITERLOOP_END >>>> >>>> >>>> with (eventually) >>>> >>>> FOREACH_VNET(vnet) { >>>> stuff >>>> } >>>> >>>> but that would require that the entire contents of "stuff" >>>> would appear in the diff. >>> >>> Thinking about it more, at a minimum, I think we should do: >>> VNET_ITERLOOP_BEGIN >>> stuff >>> VNET_ITERLOOP_END >> >> FWIW, I think we should make the change to FOREACH_VNET(vnet() { } >> sooner rather than later -- especially if there's no semantic change >> going on currently, now would be the time to do the indentation change. >> >>>> I'm not sure I want to actually include the contents directly into >>>> if.h or any other place.. I think keeping a separate vnet.h and >>>> vinet.h seems ok to me. >>> >>> The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if >>> it's going to be included in another header (IMO, the vnet/vinet.h >>> files aren't a good idea in the long term). >> >> My views on this one are a bit mixed -- if the goal is to get, in the >> medium term, to a case where we do explicit dereferencing rather than >> macros, we may find we do need more globally visible types than we had >> before, which may require us to have new globally included headers. >> That said, in.h might be as good a place as any for global inet stuff, >> and as long as we have piles of pointers rather than nested structs, >> the type issue shouldn't get too bad. > > thats' where vinet is, but what about vnet.. (non inet stuff) > I have it off if.h right now.. moved to if_var.h > >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge > > _______________________________________________ > 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 alex.wilkinson at dsto.defence.gov.au Thu Sep 4 05:12:57 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Thu Sep 4 05:13:04 2008 Subject: live & onlinedemo with freebsd 7.0 ? In-Reply-To: References: Message-ID: <20080904050147.GJ43166@stlux503.dsto.defence.gov.au> 0n Wed, Sep 03, 2008 at 03:26:50PM +0100, Robert Watson wrote: >Something to be aware of is that currently FreeBSD 7.x doesn't >support Xen out of the box, although 8.x does, and 7.x will at some point. Only as a DomU right ? Not Dom0 ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From julian at elischer.org Thu Sep 4 17:34:31 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 4 17:34:41 2008 Subject: vimage commit 1.5 Message-ID: <48C01C2D.7010903@elischer.org> The vimage-commit2 branch is pretty much ready for commit as far as I can see. The aim of this commit is to add more stuff from the vimage branch that evaluates to 0 bytes of binary change when VIMAGE is not enabled. I will have to concentrate on work for a while so I will not be 'monitoring', but I will be reachable. Bjoern, what is the commit plan? julian From julian at elischer.org Thu Sep 4 19:44:05 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 4 19:44:12 2008 Subject: next vimage commit.. a comment Message-ID: <48C03A8B.4050607@elischer.org> Some have suggested that we change the VNET_ITERLOOP_BEGIN() / VNET_ITERLOOP_END() code, and thinking about this I suggest that we go straight for the final solution of: change: code code code to: FOREACH_VNET(VINET, vnet_inet) { code code code } straight away. and get it over and done with... anyone have thoughts? From brooks at freebsd.org Thu Sep 4 19:49:57 2008 From: brooks at freebsd.org (Brooks Davis) Date: Thu Sep 4 19:50:03 2008 Subject: next vimage commit.. a comment In-Reply-To: <48C03A8B.4050607@elischer.org> References: <48C03A8B.4050607@elischer.org> Message-ID: <20080904195031.GB4117@lor.one-eyed-alien.net> On Thu, Sep 04, 2008 at 12:44:11PM -0700, Julian Elischer wrote: > Some have suggested that we change the VNET_ITERLOOP_BEGIN() / > VNET_ITERLOOP_END() code, > and thinking about this I suggest that we go straight for the > final solution of: > > change: > code > code > code > > to: > > FOREACH_VNET(VINET, vnet_inet) { > code > code > code > } > > straight away. and get it over and done with... > > anyone have thoughts? I agree. We should avoid committing new code we plan to rip up later. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080904/d3725e78/attachment.pgp From julian at elischer.org Thu Sep 4 19:53:47 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 4 19:53:54 2008 Subject: next vimage commit.. a comment In-Reply-To: <20080904195031.GB4117@lor.one-eyed-alien.net> References: <48C03A8B.4050607@elischer.org> <20080904195031.GB4117@lor.one-eyed-alien.net> Message-ID: <48C03CD1.3010908@elischer.org> Brooks Davis wrote: > On Thu, Sep 04, 2008 at 12:44:11PM -0700, Julian Elischer wrote: >> Some have suggested that we change the VNET_ITERLOOP_BEGIN() / >> VNET_ITERLOOP_END() code, >> and thinking about this I suggest that we go straight for the >> final solution of: >> >> change: >> code >> code >> code >> >> to: >> >> FOREACH_VNET(VINET, vnet_inet) { >> code >> code >> code >> } >> >> straight away. and get it over and done with... >> >> anyone have thoughts? > > I agree. We should avoid committing new code we plan to rip up later. > > -- Brooks Ok well it's going to massively expand the size of this commit diff but if we are convinced that we will "understand" that it does nothing (yet) then we can still review it for "no binary changes" relatively easily once this happens.. From zec at fer.hr Thu Sep 4 20:11:41 2008 From: zec at fer.hr (Marko Zec) Date: Thu Sep 4 20:22:10 2008 Subject: next vimage commit.. a comment In-Reply-To: <20080904195031.GB4117@lor.one-eyed-alien.net> References: <48C03A8B.4050607@elischer.org> <20080904195031.GB4117@lor.one-eyed-alien.net> Message-ID: <200809042154.45130.zec@fer.hr> On Thursday 04 September 2008 21:50:31 Brooks Davis wrote: > On Thu, Sep 04, 2008 at 12:44:11PM -0700, Julian Elischer wrote: > > Some have suggested that we change the VNET_ITERLOOP_BEGIN() / > > VNET_ITERLOOP_END() code, > > and thinking about this I suggest that we go straight for the > > final solution of: > > > > change: > > code > > code > > code > > > > to: > > > > FOREACH_VNET(VINET, vnet_inet) { > > code > > code > > code > > } > > > > straight away. and get it over and done with... > > > > anyone have thoughts? > > I agree. We should avoid committing new code we plan to rip up > later. OK I'll do this Marko From julian at elischer.org Thu Sep 4 23:58:26 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Sep 4 23:58:32 2008 Subject: vimage-commit2 kernel running smoothly Message-ID: <48C07628.8060602@elischer.org> Just to prove that the theory that we are not making actual changes is born out in practice, my test machine is running that kernel and it seems indistinguishable from the normal one. From jamie at gritton.org Fri Sep 5 16:00:49 2008 From: jamie at gritton.org (James Gritton) Date: Fri Sep 5 16:00:56 2008 Subject: The kinds of things jails could virtualize Message-ID: <48C157AA.7080702@gritton.org> The ability to turn on and off the virtualization of different parts of jails goes along with a hierarchical naming of jail parameters (not to be confused with jails themselves being hierarchical). In my current jail_set perforce branch, this is done for the hostname and related properties. There are a group of parameters under the "host" heading that customize a jail's identity to user space: host.hostname host.domainname host.hostid host.hostuuid A jail may be set to not use any of these by setting the boolean parameter "host" to false; in that case, the hostname and such are taken from the parent jail (or from the system in the non-hierarchical case). Setting it to true, or setting any one of the individual parameters, causes all the related parameters to be virtualized with initial values taken from the parent. The jail IP address and chrooted path can also be turned off, though neither is part of a formal group like the "host" stuff. IP probably should be, as turning off IP address virtualization is better left separate from specifying which addresses to restrict to. Thus perhaps an "ip" group with "ip.ip4" and "ip.ip6" parameters. The vnet stuff from vimage can also be turned off with the boolean "vnet" parameter, though there's not much other interface with the jail system other than whether it's on or off (there are a couple of read-only stat values). This would be typical of how new modules or subsystems are handled. SYSV IPC should follow a similar route. Something else worth controlling that's currently always on for jails is process hiding. It might just be a single "proc" boolean, though there may be other "proc.*" parameters that could be added later, such as future plans I have for a virtual init process. So what categories should we have for jail virtualization control? The ones I can think of are: cpu: for cpuset and other per-jail scheduling, virtual load averages, stuff of that sort. host: the hostname and related stuff above. There's also currently a sysctl "security.jail.set_hostname_allowed" that would fit better here, perhaps a boolean "host.allowed". ip: whether IP addresses are restricted or otherwise virtualized. I have no idea what "otherwise virtualized" means, but if someone comes up with anything (besides vnet which is its own beast) it may belong here. proc: whether jails can see or act on other jails' processes. There's some overlap with users as well, as that's the non-jail way of deciding process permissions. sysvipc: each jail should optionally have its own SYSV namespace. There's also the same permission issue of "host". Similar to this are a few non-SYSV IPC things like POSIX semaphores - should they have their own category, or perhaps should this be a wider "ipc" category? vnet: whether a jail is also a new vimage node, just for the VIMAGE option. - Jamie From julian at elischer.org Fri Sep 5 19:15:24 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 5 19:15:31 2008 Subject: The kinds of things jails could virtualize In-Reply-To: <48C157AA.7080702@gritton.org> References: <48C157AA.7080702@gritton.org> Message-ID: <48C18551.6090703@elischer.org> just "ack" ing this email. Don't have spare neurons to actually read/understand it right now.. James Gritton wrote: [...] From julian at elischer.org Sun Sep 7 06:27:04 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Sep 7 06:27:11 2008 Subject: FOREACH_VNET... Message-ID: <48C3743D.9090503@elischer.org> trying to replace VNET_ITERLOOP_{BEGIN,END} looking at an example: static void if_slowtimo(void *arg) { struct ifnet *ifp; IFNET_RLOCK(); VNET_ITERLOOP_BEGIN(); INIT_VNET_NET(curvnet); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (ifp->if_timer == 0 || --ifp->if_timer) continue; if (ifp->if_watchdog) (*ifp->if_watchdog)(ifp); } VNET_ITERLOOP_END(); IFNET_RUNLOCK(); timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); } If we expand this out we get: (reindented for readability) static void if_slowtimo(void *arg) { struct ifnet *ifp; IFNET_RLOCK(); struct vnet *vnet_iter; VNET_LIST_REF(); LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { struct vnet *saved_vnet = curvnet; curvnet = vnet_iter; INIT_VNET_NET(curvnet); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (ifp->if_timer == 0 || --ifp->if_timer) continue; if (ifp->if_watchdog) (*ifp->if_watchdog)(ifp); } curvnet = saved_vnet; } VNET_LIST_UNREF(); IFNET_RUNLOCK(); timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); } now several things leap out here.. (like, declaring variables in mid block) using different macros to try do this cleanly might lead to: static void if_slowtimo(void *arg) { struct ifnet *ifp; VNET_DECL(vnet_iter); VNET_DECL(saved_vnet); IFNET_RLOCK(); CURVNET_SAVE(saved_vnet); VNET_LIST_REF(); FOREACH_VNET(vnet_iter) { CURVNET_SET_QUIET(vnet_iter); INIT_VNET_NET(vnet_iter); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (ifp->if_timer == 0 || --ifp->if_timer) continue; if (ifp->if_watchdog) (*ifp->if_watchdog)(ifp); } } CURVNET_SET(vnet_hold); VNET_LIST_UNREF(); IFNET_RUNLOCK(); timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); } this adds a lot to the original.. I could see: using bigger macros, getting it back (size wise) to: static void if_slowtimo(void *arg) { struct ifnet *ifp; VNET_ITERATOR_DECL(vnet_iter, saved_vnet); IFNET_RLOCK(); FOREACH_VNET(vnet_iter, saved_vnet) { VNET_SWITCHTO(vnet_iter); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (ifp->if_timer == 0 || --ifp->if_timer) continue; if (ifp->if_watchdog) (*ifp->if_watchdog)(ifp); } } FOREACH_VNET_COMPLETE(saved_vnet); IFNET_RUNLOCK(); timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); } still bigger than the original macros though arguably more "C-like" anyone have better ways to express this? Brook, robert, bz? does this look better? Julian From julian at elischer.org Sun Sep 7 06:33:43 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Sep 7 06:33:50 2008 Subject: FOREACH_VNET... In-Reply-To: <48C3743D.9090503@elischer.org> References: <48C3743D.9090503@elischer.org> Message-ID: <48C375CD.3010308@elischer.org> Julian Elischer wrote: oops.. with correct indenting and some slight renaming.. > > static void > if_slowtimo(void *arg) > { > struct ifnet *ifp; > VNET_ITERATOR_DECL(vnet_iter, saved_vnet); > > IFNET_RLOCK(); > VNET_FOREACH(vnet_iter, saved_vnet) { > VNET_SWITCHTO(vnet_iter); > TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > if (ifp->if_timer == 0 || --ifp->if_timer) > continue; > if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > } > } > VNET_FOREACH_RESTORE(saved_vnet); > IFNET_RUNLOCK(); > timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > } >\ From zec at freebsd.org Sun Sep 7 14:41:38 2008 From: zec at freebsd.org (Marko Zec) Date: Sun Sep 7 14:42:19 2008 Subject: FOREACH_VNET... In-Reply-To: <48C3743D.9090503@elischer.org> References: <48C3743D.9090503@elischer.org> Message-ID: <200809071641.11333.zec@freebsd.org> On Sunday 07 September 2008 08:27:09 Julian Elischer wrote: > trying to replace VNET_ITERLOOP_{BEGIN,END} > > > > looking at an example: > > static void > if_slowtimo(void *arg) > { > struct ifnet *ifp; > > IFNET_RLOCK(); > VNET_ITERLOOP_BEGIN(); > INIT_VNET_NET(curvnet); > TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > if (ifp->if_timer == 0 || --ifp->if_timer) > continue; > if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > } > VNET_ITERLOOP_END(); > IFNET_RUNLOCK(); > timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > } > > > If we expand this out we get: (reindented for readability) > > static void > if_slowtimo(void *arg) > { > struct ifnet *ifp; > > IFNET_RLOCK(); > struct vnet *vnet_iter; > VNET_LIST_REF(); > LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { > struct vnet *saved_vnet = curvnet; > curvnet = vnet_iter; > INIT_VNET_NET(curvnet); > TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > if (ifp->if_timer == 0 || --ifp->if_timer) > continue; > if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > } > curvnet = saved_vnet; > } > VNET_LIST_UNREF(); > IFNET_RUNLOCK(); > timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > } > > now several things leap out here.. > (like, declaring variables in mid block) > using different macros to try do this cleanly might lead to: > > > > static void > if_slowtimo(void *arg) > { > struct ifnet *ifp; > VNET_DECL(vnet_iter); > VNET_DECL(saved_vnet); > > IFNET_RLOCK(); > CURVNET_SAVE(saved_vnet); > VNET_LIST_REF(); > FOREACH_VNET(vnet_iter) { > > CURVNET_SET_QUIET(vnet_iter); > INIT_VNET_NET(vnet_iter); > TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > if (ifp->if_timer == 0 || --ifp->if_timer) > continue; > if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > } > } > CURVNET_SET(vnet_hold); > VNET_LIST_UNREF(); > IFNET_RUNLOCK(); > timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > } > > this adds a lot to the original.. > > I could see: > > using bigger macros, getting it back (size wise) to: > > static void > if_slowtimo(void *arg) > { > struct ifnet *ifp; > VNET_ITERATOR_DECL(vnet_iter, saved_vnet); > > IFNET_RLOCK(); > FOREACH_VNET(vnet_iter, saved_vnet) { > VNET_SWITCHTO(vnet_iter); > TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > if (ifp->if_timer == 0 || --ifp->if_timer) > continue; > if (ifp->if_watchdog) > (*ifp->if_watchdog)(ifp); > } > } > FOREACH_VNET_COMPLETE(saved_vnet); > IFNET_RUNLOCK(); > timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > } > > still bigger than the original macros though arguably more "C-like" > > anyone have better ways to express this? > > Brook, robert, bz? does this look better? I don't think we need an explicit CURVNET_SAVE() in most of the places that iterate over the entire vnet list, because in functions where iteration takes place there's typically no vnet context set on entry. So perhaps a replacement for current VNET_ITERLOOP_BEGIN / VNET_ITERLOOP_END kludge looking like this could suffice: VNET_LIST_REF(); /* essentialy a RLOCK() */ VNET_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); /* existing code chunk body, 1-tab indent prepended */ CURVNET_RESTORE(); } VNET_LIST_UNREF(); /* essentially a RUNLOCK() */ This could provide more insight into what's going on in the loop, while still allowing for all the macros to vanish in nooptions VIMAGE builds. Marko From julian at elischer.org Sun Sep 7 15:34:16 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Sep 7 15:34:23 2008 Subject: FOREACH_VNET... In-Reply-To: <200809071641.11333.zec@freebsd.org> References: <48C3743D.9090503@elischer.org> <200809071641.11333.zec@freebsd.org> Message-ID: <48C3F47E.30407@elischer.org> Marko Zec wrote: > On Sunday 07 September 2008 08:27:09 Julian Elischer wrote: >> trying to replace VNET_ITERLOOP_{BEGIN,END} >> >> >> >> looking at an example: >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> >> IFNET_RLOCK(); >> VNET_ITERLOOP_BEGIN(); >> INIT_VNET_NET(curvnet); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> VNET_ITERLOOP_END(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> >> If we expand this out we get: (reindented for readability) >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> >> IFNET_RLOCK(); >> struct vnet *vnet_iter; >> VNET_LIST_REF(); >> LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { >> struct vnet *saved_vnet = curvnet; >> curvnet = vnet_iter; >> INIT_VNET_NET(curvnet); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> curvnet = saved_vnet; >> } >> VNET_LIST_UNREF(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> now several things leap out here.. >> (like, declaring variables in mid block) >> using different macros to try do this cleanly might lead to: >> >> >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> VNET_DECL(vnet_iter); >> VNET_DECL(saved_vnet); >> >> IFNET_RLOCK(); >> CURVNET_SAVE(saved_vnet); >> VNET_LIST_REF(); >> FOREACH_VNET(vnet_iter) { >> >> CURVNET_SET_QUIET(vnet_iter); >> INIT_VNET_NET(vnet_iter); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> } >> CURVNET_SET(vnet_hold); >> VNET_LIST_UNREF(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> this adds a lot to the original.. >> >> I could see: >> >> using bigger macros, getting it back (size wise) to: >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> VNET_ITERATOR_DECL(vnet_iter, saved_vnet); >> >> IFNET_RLOCK(); >> FOREACH_VNET(vnet_iter, saved_vnet) { >> VNET_SWITCHTO(vnet_iter); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> } >> FOREACH_VNET_COMPLETE(saved_vnet); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> still bigger than the original macros though arguably more "C-like" >> >> anyone have better ways to express this? >> >> Brook, robert, bz? does this look better? > > I don't think we need an explicit CURVNET_SAVE() in most of the places > that iterate over the entire vnet list, because in functions where > iteration takes place there's typically no vnet context set on entry. > > So perhaps a replacement for current VNET_ITERLOOP_BEGIN / > VNET_ITERLOOP_END kludge looking like this could suffice: > > VNET_LIST_REF(); /* essentialy a RLOCK() */ > VNET_FOREACH(vnet_iter) { vnet_iter is still being decalared mid block, which may be ok in current gcc but worries me. Also, we still need the INIT_VNET_XXX(curvnet) as well. > CURVNET_SET(vnet_iter); > /* existing code chunk body, 1-tab indent prepended */ > CURVNET_RESTORE(); > } > VNET_LIST_UNREF(); /* essentially a RUNLOCK() */ > > This could provide more insight into what's going on in the loop, while > still allowing for all the macros to vanish in nooptions VIMAGE builds. > > Marko > _______________________________________________ > 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 Sep 7 15:36:01 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Sep 7 15:36:07 2008 Subject: FOREACH_VNET... In-Reply-To: <200809071641.11333.zec@freebsd.org> References: <48C3743D.9090503@elischer.org> <200809071641.11333.zec@freebsd.org> Message-ID: <48C3F4E7.6030507@elischer.org> Marko Zec wrote: > On Sunday 07 September 2008 08:27:09 Julian Elischer wrote: >> trying to replace VNET_ITERLOOP_{BEGIN,END} >> >> >> >> looking at an example: >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> >> IFNET_RLOCK(); >> VNET_ITERLOOP_BEGIN(); >> INIT_VNET_NET(curvnet); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> VNET_ITERLOOP_END(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> >> If we expand this out we get: (reindented for readability) >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> >> IFNET_RLOCK(); >> struct vnet *vnet_iter; >> VNET_LIST_REF(); >> LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { >> struct vnet *saved_vnet = curvnet; >> curvnet = vnet_iter; >> INIT_VNET_NET(curvnet); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> curvnet = saved_vnet; >> } >> VNET_LIST_UNREF(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> now several things leap out here.. >> (like, declaring variables in mid block) >> using different macros to try do this cleanly might lead to: >> >> >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> VNET_DECL(vnet_iter); >> VNET_DECL(saved_vnet); >> >> IFNET_RLOCK(); >> CURVNET_SAVE(saved_vnet); >> VNET_LIST_REF(); >> FOREACH_VNET(vnet_iter) { >> >> CURVNET_SET_QUIET(vnet_iter); >> INIT_VNET_NET(vnet_iter); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> } >> CURVNET_SET(vnet_hold); >> VNET_LIST_UNREF(); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> this adds a lot to the original.. >> >> I could see: >> >> using bigger macros, getting it back (size wise) to: >> >> static void >> if_slowtimo(void *arg) >> { >> struct ifnet *ifp; >> VNET_ITERATOR_DECL(vnet_iter, saved_vnet); >> >> IFNET_RLOCK(); >> FOREACH_VNET(vnet_iter, saved_vnet) { >> VNET_SWITCHTO(vnet_iter); >> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >> if (ifp->if_timer == 0 || --ifp->if_timer) >> continue; >> if (ifp->if_watchdog) >> (*ifp->if_watchdog)(ifp); >> } >> } >> FOREACH_VNET_COMPLETE(saved_vnet); >> IFNET_RUNLOCK(); >> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >> } >> >> still bigger than the original macros though arguably more "C-like" >> >> anyone have better ways to express this? >> >> Brook, robert, bz? does this look better? > > I don't think we need an explicit CURVNET_SAVE() in most of the places > that iterate over the entire vnet list, because in functions where > iteration takes place there's typically no vnet context set on entry. > > So perhaps a replacement for current VNET_ITERLOOP_BEGIN / > VNET_ITERLOOP_END kludge looking like this could suffice: > > VNET_LIST_REF(); /* essentialy a RLOCK() */ > VNET_FOREACH(vnet_iter) { > CURVNET_SET(vnet_iter); > /* existing code chunk body, 1-tab indent prepended */ > CURVNET_RESTORE(); > } > VNET_LIST_UNREF(); /* essentially a RUNLOCK() */ also. it it enough to just have a reference? is there a (rw)lock for the vimage list? > > This could provide more insight into what's going on in the loop, while > still allowing for all the macros to vanish in nooptions VIMAGE builds. > > Marko > _______________________________________________ > 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 brooks at freebsd.org Mon Sep 8 14:27:09 2008 From: brooks at freebsd.org (Brooks Davis) Date: Mon Sep 8 14:27:18 2008 Subject: FOREACH_VNET... In-Reply-To: <48C3F47E.30407@elischer.org> References: <48C3743D.9090503@elischer.org> <200809071641.11333.zec@freebsd.org> <48C3F47E.30407@elischer.org> Message-ID: <20080908142757.GB20793@lor.one-eyed-alien.net> On Sun, Sep 07, 2008 at 08:34:22AM -0700, Julian Elischer wrote: > Marko Zec wrote: >> On Sunday 07 September 2008 08:27:09 Julian Elischer wrote: >>> trying to replace VNET_ITERLOOP_{BEGIN,END} >>> >>> >>> >>> looking at an example: >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> >>> IFNET_RLOCK(); >>> VNET_ITERLOOP_BEGIN(); >>> INIT_VNET_NET(curvnet); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> VNET_ITERLOOP_END(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> >>> If we expand this out we get: (reindented for readability) >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> >>> IFNET_RLOCK(); >>> struct vnet *vnet_iter; >>> VNET_LIST_REF(); >>> LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { >>> struct vnet *saved_vnet = curvnet; >>> curvnet = vnet_iter; >>> INIT_VNET_NET(curvnet); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> curvnet = saved_vnet; >>> } >>> VNET_LIST_UNREF(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> now several things leap out here.. >>> (like, declaring variables in mid block) >>> using different macros to try do this cleanly might lead to: >>> >>> >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> VNET_DECL(vnet_iter); >>> VNET_DECL(saved_vnet); >>> >>> IFNET_RLOCK(); >>> CURVNET_SAVE(saved_vnet); >>> VNET_LIST_REF(); >>> FOREACH_VNET(vnet_iter) { >>> >>> CURVNET_SET_QUIET(vnet_iter); >>> INIT_VNET_NET(vnet_iter); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> } >>> CURVNET_SET(vnet_hold); >>> VNET_LIST_UNREF(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> this adds a lot to the original.. >>> >>> I could see: >>> >>> using bigger macros, getting it back (size wise) to: >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> VNET_ITERATOR_DECL(vnet_iter, saved_vnet); >>> >>> IFNET_RLOCK(); >>> FOREACH_VNET(vnet_iter, saved_vnet) { >>> VNET_SWITCHTO(vnet_iter); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> } >>> FOREACH_VNET_COMPLETE(saved_vnet); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> still bigger than the original macros though arguably more "C-like" >>> >>> anyone have better ways to express this? >>> >>> Brook, robert, bz? does this look better? >> >> I don't think we need an explicit CURVNET_SAVE() in most of the places >> that iterate over the entire vnet list, because in functions where >> iteration takes place there's typically no vnet context set on entry. >> >> So perhaps a replacement for current VNET_ITERLOOP_BEGIN / >> VNET_ITERLOOP_END kludge looking like this could suffice: >> >> VNET_LIST_REF(); /* essentialy a RLOCK() */ >> VNET_FOREACH(vnet_iter) { > > vnet_iter is still being decalared mid block, which may be ok in current > gcc but worries me. > Also, we still need the INIT_VNET_XXX(curvnet) as well. I'd like to see some sort of VNET_ITERATOR_DECL(vnet_iter) at the top rather than the mid-block decleration. -- Brooks > >> CURVNET_SET(vnet_iter); >> /* existing code chunk body, 1-tab indent prepended */ >> CURVNET_RESTORE(); >> } >> VNET_LIST_UNREF(); /* essentially a RUNLOCK() */ >> >> This could provide more insight into what's going on in the loop, while >> still allowing for all the macros to vanish in nooptions VIMAGE builds. >> >> Marko >> _______________________________________________ >> 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080908/9eba96a3/attachment.pgp From brooks at freebsd.org Mon Sep 8 14:29:16 2008 From: brooks at freebsd.org (Brooks Davis) Date: Mon Sep 8 14:29:22 2008 Subject: FOREACH_VNET... In-Reply-To: <48C3F4E7.6030507@elischer.org> References: <48C3743D.9090503@elischer.org> <200809071641.11333.zec@freebsd.org> <48C3F4E7.6030507@elischer.org> Message-ID: <20080908143004.GC20793@lor.one-eyed-alien.net> On Sun, Sep 07, 2008 at 08:36:07AM -0700, Julian Elischer wrote: > Marko Zec wrote: >> On Sunday 07 September 2008 08:27:09 Julian Elischer wrote: >>> trying to replace VNET_ITERLOOP_{BEGIN,END} >>> >>> >>> >>> looking at an example: >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> >>> IFNET_RLOCK(); >>> VNET_ITERLOOP_BEGIN(); >>> INIT_VNET_NET(curvnet); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> VNET_ITERLOOP_END(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> >>> If we expand this out we get: (reindented for readability) >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> >>> IFNET_RLOCK(); >>> struct vnet *vnet_iter; >>> VNET_LIST_REF(); >>> LIST_FOREACH(vnet_iter, &vnet_head, vnet_le) { >>> struct vnet *saved_vnet = curvnet; >>> curvnet = vnet_iter; >>> INIT_VNET_NET(curvnet); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> curvnet = saved_vnet; >>> } >>> VNET_LIST_UNREF(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> now several things leap out here.. >>> (like, declaring variables in mid block) >>> using different macros to try do this cleanly might lead to: >>> >>> >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> VNET_DECL(vnet_iter); >>> VNET_DECL(saved_vnet); >>> >>> IFNET_RLOCK(); >>> CURVNET_SAVE(saved_vnet); >>> VNET_LIST_REF(); >>> FOREACH_VNET(vnet_iter) { >>> >>> CURVNET_SET_QUIET(vnet_iter); >>> INIT_VNET_NET(vnet_iter); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> } >>> CURVNET_SET(vnet_hold); >>> VNET_LIST_UNREF(); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> this adds a lot to the original.. >>> >>> I could see: >>> >>> using bigger macros, getting it back (size wise) to: >>> >>> static void >>> if_slowtimo(void *arg) >>> { >>> struct ifnet *ifp; >>> VNET_ITERATOR_DECL(vnet_iter, saved_vnet); >>> >>> IFNET_RLOCK(); >>> FOREACH_VNET(vnet_iter, saved_vnet) { >>> VNET_SWITCHTO(vnet_iter); >>> TAILQ_FOREACH(ifp, &V_ifnet, if_link) { >>> if (ifp->if_timer == 0 || --ifp->if_timer) >>> continue; >>> if (ifp->if_watchdog) >>> (*ifp->if_watchdog)(ifp); >>> } >>> } >>> FOREACH_VNET_COMPLETE(saved_vnet); >>> IFNET_RUNLOCK(); >>> timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); >>> } >>> >>> still bigger than the original macros though arguably more "C-like" >>> >>> anyone have better ways to express this? >>> >>> Brook, robert, bz? does this look better? >> >> I don't think we need an explicit CURVNET_SAVE() in most of the places >> that iterate over the entire vnet list, because in functions where >> iteration takes place there's typically no vnet context set on entry. >> >> So perhaps a replacement for current VNET_ITERLOOP_BEGIN / >> VNET_ITERLOOP_END kludge looking like this could suffice: >> >> VNET_LIST_REF(); /* essentialy a RLOCK() */ >> VNET_FOREACH(vnet_iter) { >> CURVNET_SET(vnet_iter); >> /* existing code chunk body, 1-tab indent prepended */ >> CURVNET_RESTORE(); >> } >> VNET_LIST_UNREF(); /* essentially a RUNLOCK() */ > > also. it it enough to just have a reference? is there a (rw)lock for > the vimage list? This really needs to be changed to the appropriate real lock (sx, rw, or rm) rather than a hand rolled version. Unless another syncronization mechanism does not provide what we need, we should always error on the side of using the existing primative. -- Brooks >> >> This could provide more insight into what's going on in the loop, while >> still allowing for all the macros to vanish in nooptions VIMAGE builds. >> >> Marko >> _______________________________________________ >> 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080908/81879890/attachment.pgp From julian at elischer.org Wed Sep 10 08:10:01 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 10 08:10:08 2008 Subject: Vnet iteration In-Reply-To: <200809081655.m88GtxbV000906@repoman.freebsd.org> References: <200809081655.m88GtxbV000906@repoman.freebsd.org> Message-ID: <48C780E4.2050207@elischer.org> Marko Zec wrote: > http://perforce.freebsd.org/chv.cgi?CH=149433 > > Change 149433 by zec@zec_tpx32 on 2008/09/08 16:55:34 > > First-cut replacement of VNET_ITERLOOP_BEGIN() / > VNET_ITERLOOP_END() kludges with VNET_FOREACH() constructs > discussed at freebsd-virtualization@ > > Needs a bit more testing before merging over to > vimage-commit2 branch. > > Affected files ... > > .. //depot/projects/vimage/src/sys/dev/cxgb/ulp/iw_cxgb/iw_cxgb.c#3 edit > .. //depot/projects/vimage/src/sys/kern/kern_vimage.c#66 edit > .. //depot/projects/vimage/src/sys/net/if.c#36 edit > .. //depot/projects/vimage/src/sys/net/if_ef.c#6 edit > .. //depot/projects/vimage/src/sys/net80211/ieee80211_ddb.c#8 edit > .. //depot/projects/vimage/src/sys/netgraph/atm/ng_atm.c#6 edit > .. //depot/projects/vimage/src/sys/netgraph/ng_gif.c#7 edit > .. //depot/projects/vimage/src/sys/netinet/igmp.c#15 edit > .. //depot/projects/vimage/src/sys/netinet/in_pcb.c#29 edit > .. //depot/projects/vimage/src/sys/netinet/in_rmx.c#18 edit > .. //depot/projects/vimage/src/sys/netinet/ip_input.c#32 edit > .. //depot/projects/vimage/src/sys/netinet/tcp_subr.c#47 edit > .. //depot/projects/vimage/src/sys/netinet/tcp_timer.c#20 edit > .. //depot/projects/vimage/src/sys/netinet6/frag6.c#17 edit > .. //depot/projects/vimage/src/sys/netipsec/key.c#20 edit > .. //depot/projects/vimage/src/sys/sys/vimage.h#63 edit > > Differences ... [...] > + VNET_FOREACH(vnet_iter) { > + CURVNET_SET(vnet_iter); /* XXX CURVNET_SET_QUIET() ? */ > + INIT_VNET_NET(vnet_iter); > + TAILQ_FOREACH(ifp, &V_ifnet, if_link) > + (void)ifaddr_event_handler(NULL, ifp); > + CURVNET_RESTORE(); > } this looks great.. I'd like to see as much of this as possible in commit2 and then I'd like to see it committed as soon as brokk, bz and others have kicked the t[yi]res a bit. :-) From julian at elischer.org Wed Sep 10 20:03:27 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 10 20:03:33 2008 Subject: latest vimage kernel has some problems.. Message-ID: <48C8281A.3080505@elischer.org> Marko, I think some locking changes recently may have frightenned the vimage system.. ;-) sorry about the wrapping.. my Mail program seems to not like this sort of thing.. root@trafmon2:root(26) vimage -i fred bge1 bge1 panic: mutex ifnet not owned at ../../../net/if.c:206 cpuid = 0 KDB: enter: panic [thread pid 1328 tid 100128 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 1328 tid 100128 td 0xc699c690 kdb_enter(c0b2456d,c0b2456d,c0b23034,f0c59ac8,0,...) at kdb_enter+0x3a panic(c0b23034,c0b32f47,c0b32abf,ce,f0c59afc,...) at panic+0x12c _mtx_assert(c0dc8a64,4,c0b32abf,ce,f0c59b24,...) at _mtx_assert+0x87 ifnet_setbyindex(2,0,c60aa500,c60aa500,27,...) at ifnet_setbyindex+0xa2 if_reassign_common(c62b4800,c6a70000,c0b331d4,0,c0b32abf,...) at if_reassign_common+0x92 ether_reassign(c62b4800,c6a70000,c6ae7828,1,c6a70000,...) at ether_reassign+0x5c vi_if_move(c6ae7000,0,c607e000,c0b1ff2f,c6054948,...) at vi_if_move+0x1c1 ifioctl(c68924a4,cc3c6967,c6ae7000,c699c690,c0784fda,...) at ifioctl+0xfb soo_ioctl(c65c05e8,cc3c6967,c6ae7000,c65b1a00,c699c690,...) at soo_ioctl+0x467 kern_ioctl(c699c690,3,cc3c6967,c6ae7000,1b565af,...) at kern_ioctl+0x1dd ioctl(c699c690,f0c59cf8,c,f0c59d38,c0bf8450,...) at ioctl+0x134 syscall(f0c59d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816cae3, esp = 0xbfbfdfec, ebp = 0xbfbfec88 --- db> From julian at elischer.org Wed Sep 10 20:10:25 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 10 20:10:30 2008 Subject: latest vimage kernel has some problems.. In-Reply-To: <48C8281A.3080505@elischer.org> References: <48C8281A.3080505@elischer.org> Message-ID: <48C829BC.3060809@elischer.org> Julian Elischer wrote: > Marko, > > I think some locking changes recently may have frightenned the vimage > system.. ;-) oops I see you jsut fixed this.. (recompiling....) > > > sorry about the wrapping.. my Mail program seems to not like > this sort of thing.. > > root@trafmon2:root(26) vimage -i fred bge1 bge1 > panic: mutex ifnet not owned at ../../../net/if.c:206 > cpuid = 0 > KDB: enter: panic > [thread pid 1328 tid 100128 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> bt > Tracing pid 1328 tid 100128 td 0xc699c690 > kdb_enter(c0b2456d,c0b2456d,c0b23034,f0c59ac8,0,...) at kdb_enter+0x3a > panic(c0b23034,c0b32f47,c0b32abf,ce,f0c59afc,...) at panic+0x12c > _mtx_assert(c0dc8a64,4,c0b32abf,ce,f0c59b24,...) at _mtx_assert+0x87 > ifnet_setbyindex(2,0,c60aa500,c60aa500,27,...) at ifnet_setbyindex+0xa2 > if_reassign_common(c62b4800,c6a70000,c0b331d4,0,c0b32abf,...) at > if_reassign_common+0x92 > ether_reassign(c62b4800,c6a70000,c6ae7828,1,c6a70000,...) at > ether_reassign+0x5c > vi_if_move(c6ae7000,0,c607e000,c0b1ff2f,c6054948,...) at vi_if_move+0x1c1 > ifioctl(c68924a4,cc3c6967,c6ae7000,c699c690,c0784fda,...) at ifioctl+0xfb > soo_ioctl(c65c05e8,cc3c6967,c6ae7000,c65b1a00,c699c690,...) at > soo_ioctl+0x467 > kern_ioctl(c699c690,3,cc3c6967,c6ae7000,1b565af,...) at kern_ioctl+0x1dd > ioctl(c699c690,f0c59cf8,c,f0c59d38,c0bf8450,...) at ioctl+0x134 > syscall(f0c59d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816cae3, esp = > 0xbfbfdfec, ebp = 0xbfbfec88 --- > db> > _______________________________________________ > 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 mehulc87 at gmail.com Thu Sep 11 17:42:58 2008 From: mehulc87 at gmail.com (Mehul Chadha) Date: Thu Sep 11 17:43:05 2008 Subject: Adding Virtual kernel support to FreeBSD Message-ID: <251d650c0809111021w6f3e3586pb81918ec1f10eb8b@mail.gmail.com> hello all, We are a group of 3 students doing their graduation in computer science. We were thinking of implementing the virtual kernel support to freeBSD similar to what user mode linux does . We would be very thankful if we can have some suggestions and advice from your side. Thanks and Regards, Mehul From steve at energistic.com Fri Sep 12 04:03:33 2008 From: steve at energistic.com (Steve Ames) Date: Fri Sep 12 04:03:39 2008 Subject: xen update In-Reply-To: <3c1674c90808222138v12d7b9f8q5230273b076b3b43@mail.gmail.com> References: <3c1674c90808222138v12d7b9f8q5230273b076b3b43@mail.gmail.com> Message-ID: <20080912033401.GA61061@energistic.com> Hello, just now getting a chance to test. I am likely doing something wrong :) I did the following: 1. Installed a fresh FreeBSD 8-CURRENT system using the latest snapshot ISO 2. Updated code and did makeworld && make installworld 3. Built a kernel using the stock XEN kernel config file 4. On blank partition I created an image in the following manner: dd if=/dev/zero of=xen.img bs=1024k count=5132 mdconfig -a -t vnode -f xen.img -u 3 bsdlabel -w md3 bsdlabel -e md3 (where I created 2 partitions: / on a and swap on b) newfs /dev/md3a mount /dev/md3a /mnt (copied all data from theFreebsd8 partition to /dev/md3a using backup | restor) 5. Modified /mnt/etc/fstab and /mnt/etc/ttys 6. Copied /mnt/boo/kernel/kernel and my newly created xen.img files to a CentOS 5 server which has Xen 3.1 I believe. 7. Created a xen load file: name = "fbsd8" kernel = "/root/kernel.bsd8" vif = [ 'bridge=xenbr1' ] memory = 256 disk = [ 'file://root/xen.img,0x01,w' ] vcpus=1 on_crash = 'preserve' 8. started the image using 'xm create fbsd8 -c' 9. receivd the following break to debugger: Started domain fbsd8 WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Wed Sep 10 17:01:33 EDT 2008 root@:/usr/obj/usr/src/sys/XEN WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 3000.102 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x641d AMD Features=0x20000000 AMD Features2=0x1 Logical CPUs per core: 2 real memory = 268435456 (256 MB) avail memory = 255057920 (243 MB) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xbffffc00 fault code = supervisor read, page not present instruction pointer = 0x21:0xc02f429d stack pointer = 0x29:0xc0580d28 frame pointer = 0x29:0xc0580d30 code segment = base 0x0, limit 0xf9800, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 0 () [thread pid 0 tid 0 ] Stopped at MPentry+0x6d: cmpl $0x5f504d5f,kernbase(%eax) db> So... where did I go wrong? Thanks. -Steve From numardbsd at gmail.com Fri Sep 12 06:58:07 2008 From: numardbsd at gmail.com (Norberto Meijome) Date: Fri Sep 12 06:58:13 2008 Subject: {Spam?} Re: {Spam?} Re: Virtual machines hosted on FreeBSD 7 In-Reply-To: <6.0.0.22.2.20080909054031.025d14a0@mail.computinginnovations.com> References: <6.0.0.22.2.20080908221910.025e3508@mail.computinginnovations.com> <48C5EF82.8000904@gmail.com> <6.0.0.22.2.20080908224405.025edbf0@mail.computinginnovations.com> <6.0.0.22.2.20080909054031.025d14a0@mail.computinginnovations.com> Message-ID: <20080912162811.7b8e212d@ayiin> On Tue, 09 Sep 2008 05:40:58 -0500 Derek Ragona wrote: NM > > NM > >you can use qemu - it's not as good as vmware or xen, but it may be good NM > >enough. i've used it just fine for using winxp machines on my fbsd laptop. > > Did you just install qemu from the ports? > > -Derek > hi Derek, please keep the list in CC. yes, from ports. also install kqemu port and test whether using it for all qemu kernel calls or only userland makes a difference - i've found it crashing more often when using the full accel mode, but quite ok when using it for some of the syscalls only. kqemu-kmod-1.3.0.p11_9 Kernel Accelerator for QEMU CPU Emulator qemu-0.9.1_9 QEMU CPU Emulator qtemu-1.0.5_1 A Qt4 front-end to Qemu Mind you, i have only used it in a desktop environment... I don't think it is ready for a full enterprise / virtualisation solution like vmware or xen. B _________________________ {Beto|Norberto|Numard} Meijome "The distinction between past, present and future is only an illusion, even if a stubborn one" Albert Einstein I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From pfgshield-freebsd at yahoo.com Fri Sep 12 16:31:33 2008 From: pfgshield-freebsd at yahoo.com (Pedro Giffuni) Date: Fri Sep 12 17:35:53 2008 Subject: VirtualBox looks for FreeBSD developer Message-ID: <880886.92445.qm@web32705.mail.mud.yahoo.com> Hi Klaus; Thank you for your posting on -ports: http://docs.freebsd.org/cgi/mid.cgi?48C8F051.7060107 I think either -emulation or -virtualization might be better targets for such discussion though (indeed we did discuss it briefly in the virtualization list). Some of us are very interested in having VirtualBox on FreeBSD, and I understand the FreeBSD Foundation would consider sponsoring such effort if someone with the know-how makes the proposal. I don't have what's needed but I was thinking maybe someone that knows well the kqemu module would have that know-how... Perhaps you could give us more insight on what needs to be done/documented? Pedro. __________________________________________________ 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 julian at elischer.org Fri Sep 12 17:45:43 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 12 17:45:50 2008 Subject: VirtualBox looks for FreeBSD developer In-Reply-To: <880886.92445.qm@web32705.mail.mud.yahoo.com> References: <880886.92445.qm@web32705.mail.mud.yahoo.com> Message-ID: <48CAAAC5.2050707@elischer.org> Pedro Giffuni wrote: > Hi Klaus; > > Thank you for your posting on -ports: > > http://docs.freebsd.org/cgi/mid.cgi?48C8F051.7060107 > > I think either -emulation or -virtualization might be better > targets for such discussion though (indeed we did discuss it > briefly in the virtualization list). > > Some of us are very interested in having VirtualBox on FreeBSD, and > I understand the FreeBSD Foundation would consider sponsoring such > effort if someone with the know-how makes the proposal. Klause, freebsd-virtualization@freebsd.org (this mail is there) is the place you want but it is a new list and not everyone on freebsd-emulation@freebsd.org will be on it (yet). Freebsd ports is for ported software, but virtualbox doesn't really come into that category yet.. > > I don't have what's needed but I was thinking maybe someone that > knows well the kqemu module would have that know-how... Perhaps you > could give us more insight on what needs to be done/documented? A laundry list of what is needed would be good.. Remember that we have had vmware running on FreeBSD so it can be done. > > Pedro. > > > __________________________________________________ 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 > _______________________________________________ > 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 bzeeb-lists at lists.zabbadoz.net Tue Sep 16 17:45:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Sep 16 17:45:34 2008 Subject: Vnet iteration In-Reply-To: <48C780E4.2050207@elischer.org> References: <200809081655.m88GtxbV000906@repoman.freebsd.org> <48C780E4.2050207@elischer.org> Message-ID: <20080916174040.Y65801@maildrop.int.zabbadoz.net> > Marko Zec wrote: Hi, >> http://perforce.freebsd.org/chv.cgi?CH=149433 >> >> Change 149433 by zec@zec_tpx32 on 2008/09/08 16:55:34 >> >> First-cut replacement of VNET_ITERLOOP_BEGIN() / >> VNET_ITERLOOP_END() kludges with VNET_FOREACH() constructs >> discussed at freebsd-virtualization@ >> Needs a bit more testing before merging over to >> vimage-commit2 branch. >> >> Differences ... > > [...] > >> + VNET_FOREACH(vnet_iter) { >> + CURVNET_SET(vnet_iter); /* XXX CURVNET_SET_QUIET() ? */ >> + INIT_VNET_NET(vnet_iter); >> + TAILQ_FOREACH(ifp, &V_ifnet, if_link) >> + (void)ifaddr_event_handler(NULL, ifp); >> + CURVNET_RESTORE(); >> } > > this looks great.. > > I'd like to see as much of this as possible in commit2 > and then I'd like to see it committed as soon as brokk, bz and others have > kicked the t[yi]res a bit. > :-) So can anyone bring it over to commit2? Marko, are you around? I had been generating a diff last weekend again to push this and found that the diff size changed from ~200k to ~800k so I suspect there was a mis-integration or someone forgot to set the label? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From bzeeb-lists at lists.zabbadoz.net Tue Sep 16 20:10:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Sep 16 20:14:07 2008 Subject: [CFR/T] multi-/no-IP jail patch for HEAD Message-ID: <20080916200015.X65801@maildrop.int.zabbadoz.net> Hi, I have put a close to be commit candidate (if ipv4 src addr selection is in upfront) online here: http://people.freebsd.org/~bz/bz_jail-20080915-02-svn.diff This is for HEAD, for review and testing. Changes since last release: - SCTP enabled (again) for IPv4 and on for v6 as well. Might need another pari of eyes or someone to write regression tests. - jls -a/-v implemented/documented - updated ipv4 source address selection (changes semantics, please test/review carefully) - minor cleanup Please report anything you want/that need sto be/... changed/fixed/... Thanks. /bz PS: for anyone crying for RELENG_7. I am trying to put a patch together the next days. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From reddvinylene at gmail.com Tue Sep 16 21:06:10 2008 From: reddvinylene at gmail.com (Redd Vinylene) Date: Tue Sep 16 21:22:34 2008 Subject: [CFR/T] multi-/no-IP jail patch for HEAD In-Reply-To: <20080916200015.X65801@maildrop.int.zabbadoz.net> References: <20080916200015.X65801@maildrop.int.zabbadoz.net> Message-ID: On Tue, Sep 16, 2008 at 10:08 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > Hi, > > I have put a close to be commit candidate (if ipv4 src addr selection > is in upfront) online here: > > http://people.freebsd.org/~bz/bz_jail-20080915-02-svn.diff > > This is for HEAD, for review and testing. > > Changes since last release: > - SCTP enabled (again) for IPv4 and on for v6 as well. Might need > another pari of eyes or someone to write regression tests. > - jls -a/-v implemented/documented > - updated ipv4 source address selection (changes semantics, please > test/review carefully) > - minor cleanup > > Please report anything you want/that need sto be/... changed/fixed/... > > Thanks. > /bz > > > PS: for anyone crying for RELENG_7. I am trying to put a patch > together the next days. > > -- > Bjoern A. Zeeb Stop bit received. Insert coin for new game. > > Excellent work! Keep it up bro! -- http://www.home.no/reddvinylene From julian at elischer.org Wed Sep 17 01:11:34 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 17 01:11:45 2008 Subject: Vnet iteration In-Reply-To: <20080916174040.Y65801@maildrop.int.zabbadoz.net> References: <200809081655.m88GtxbV000906@repoman.freebsd.org> <48C780E4.2050207@elischer.org> <20080916174040.Y65801@maildrop.int.zabbadoz.net> Message-ID: <48D0593F.6050005@elischer.org> Bjoern A. Zeeb wrote: >> Marko Zec wrote: > > Hi, > >>> http://perforce.freebsd.org/chv.cgi?CH=149433 >>> >>> Change 149433 by zec@zec_tpx32 on 2008/09/08 16:55:34 >>> >>> First-cut replacement of VNET_ITERLOOP_BEGIN() / >>> VNET_ITERLOOP_END() kludges with VNET_FOREACH() constructs >>> discussed at freebsd-virtualization@ >>> Needs a bit more testing before merging over to >>> vimage-commit2 branch. >>> >>> Differences ... >> >> [...] >> >>> + VNET_FOREACH(vnet_iter) { >>> + CURVNET_SET(vnet_iter); /* XXX CURVNET_SET_QUIET() ? */ >>> + INIT_VNET_NET(vnet_iter); >>> + TAILQ_FOREACH(ifp, &V_ifnet, if_link) >>> + (void)ifaddr_event_handler(NULL, ifp); >>> + CURVNET_RESTORE(); >>> } >> >> this looks great.. >> >> I'd like to see as much of this as possible in commit2 >> and then I'd like to see it committed as soon as brokk, bz and others >> have kicked the t[yi]res a bit. >> :-) > > > So can anyone bring it over to commit2? Marko, are you around? I'm busy at work right now. > > I had been generating a diff last weekend again to push this and found > that the diff size changed from ~200k to ~800k so I suspect there was > a mis-integration or someone forgot to set the label? rerun the update script and select a change around the time of the last integration and it should correct the label. (on the other hand I think it's time for an update anyhow..) > > > > /bz > From steve at energistic.com Thu Sep 18 17:38:11 2008 From: steve at energistic.com (Steve Ames) Date: Thu Sep 18 17:38:17 2008 Subject: xen update References: <3c1674c90808222138v12d7b9f8q5230273b076b3b43@mail.gmail.com> <20080912033401.GA61061@energistic.com> Message-ID: Hi, can anyone point me in the right direction so I can do further testing? Steve Ames wrote: > Hello, just now getting a chance to test. I am likely doing > something wrong :) > > I did the following: > > 1. Installed a fresh FreeBSD 8-CURRENT system using the > latest snapshot ISO > 2. Updated code and did makeworld && make installworld > 3. Built a kernel using the stock XEN kernel config file > 4. On blank partition I created an image in the following > manner: > > dd if=/dev/zero of=xen.img bs=1024k count=5132 > mdconfig -a -t vnode -f xen.img -u 3 > bsdlabel -w md3 > bsdlabel -e md3 (where I created 2 partitions: / on a and swap on b) > newfs /dev/md3a > mount /dev/md3a /mnt > (copied all data from theFreebsd8 partition to /dev/md3a using backup > | restor) > > 5. Modified /mnt/etc/fstab and /mnt/etc/ttys > 6. Copied /mnt/boo/kernel/kernel and my newly created xen.img > files to a CentOS 5 server which has Xen 3.1 I believe. > 7. Created a xen load file: > > name = "fbsd8" > kernel = "/root/kernel.bsd8" > vif = [ 'bridge=xenbr1' ] > memory = 256 > disk = [ 'file://root/xen.img,0x01,w' ] > vcpus=1 > on_crash = 'preserve' > > 8. started the image using 'xm create fbsd8 -c' > > 9. receivd the following break to debugger: > > > Started domain fbsd8 > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-CURRENT #0: Wed Sep 10 17:01:33 EDT 2008 > root@:/usr/obj/usr/src/sys/XEN > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 3000.102 MHz processor. > Timecounter "ixen" frequency 1000000000 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.10-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 > > Features=0xbfebfbff > Features2=0x641d > AMD Features=0x20000000 > AMD Features2=0x1 > Logical CPUs per core: 2 > real memory = 268435456 (256 MB) > avail memory = 255057920 (243 MB) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xbffffc00 > fault code = supervisor read, page not present > instruction pointer = 0x21:0xc02f429d > stack pointer = 0x29:0xc0580d28 > frame pointer = 0x29:0xc0580d30 > code segment = base 0x0, limit 0xf9800, type 0x1b > = DPL 1, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [thread pid 0 tid 0 ] > Stopped at MPentry+0x6d: cmpl $0x5f504d5f,kernbase(%eax) > db> > > So... where did I go wrong? Thanks. > > -Steve > > _______________________________________________ > 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 antipsychic at gmail.com Thu Sep 18 18:58:07 2008 From: antipsychic at gmail.com (antipsychic) Date: Thu Sep 18 18:58:13 2008 Subject: natd & vimage Message-ID: tried making a custom kernel with IPFIREWALL and IPDIVERT options enabled, as per natd man page. build croaked on netinet/ip_divert.c: ipstat undeclared. 7-0-prerelease. have been using vimage for a test environment now since May, no serious problems, found it to be far more stable than the vmware environment was using before. need to nat now though. have no problem moving to current or whatever. going to upgrade test box to multi-core machine soon as time permits. any advise is appreciated! thanks, Jake From jeffrey.m.ahrenholz at boeing.com Thu Sep 18 20:29:57 2008 From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M) Date: Thu Sep 18 20:30:06 2008 Subject: natd & vimage In-Reply-To: References: Message-ID: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> Jake, > tried making a custom kernel with IPFIREWALL and IPDIVERT options > enabled, as per natd man page. build croaked on > netinet/ip_divert.c: > ipstat undeclared. 7-0-prerelease. > > have been using vimage for a test environment now since May, no > serious problems, found it to be far more stable than the vmware > environment was using before. if you want to use 7.0-RELEASE and the vimage_7-20080228 kernel found here http://imunes.tel.fer.hr/virtnet/, I have made a patch that allows you to load the ipdivert module with 'kldload ipdivert'. This patch may not work for compiling in the option IPDIVERT but seems to work fine as a module. Let me know and I'll post it... (if you try to kldload ipdivert with the vimage_7-20080228 kernel, it complains about that missing ipstat identifier) also this patch enables ip_mroute, but I am still debugging that part... -Jeff From julian at elischer.org Fri Sep 19 01:00:33 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 19 01:00:40 2008 Subject: natd & vimage In-Reply-To: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: <48D2F9B1.8020507@elischer.org> Ahrenholz, Jeffrey M wrote: > Jake, > >> tried making a custom kernel with IPFIREWALL and IPDIVERT options >> enabled, as per natd man page. build croaked on >> netinet/ip_divert.c: >> ipstat undeclared. 7-0-prerelease. >> >> have been using vimage for a test environment now since May, no >> serious problems, found it to be far more stable than the vmware >> environment was using before. > > if you want to use 7.0-RELEASE and the vimage_7-20080228 kernel found > here http://imunes.tel.fer.hr/virtnet/, I have made a patch that allows > you to load the ipdivert module with 'kldload ipdivert'. This patch may > not work for compiling in the option IPDIVERT but seems to work fine as > a module. Let me know and I'll post it... > > (if you try to kldload ipdivert with the vimage_7-20080228 kernel, it > complains about that missing ipstat identifier) > > also this patch enables ip_mroute, but I am still debugging that part... please make sure that your fixes go into the vimage branch.. we need all the help we can get :-) > > -Jeff > _______________________________________________ > 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 Fri Sep 19 17:55:06 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 19 17:55:18 2008 Subject: vimage and curvnet. In-Reply-To: <200809191743.m8JHhZj8009388@repoman.freebsd.org> References: <200809191743.m8JHhZj8009388@repoman.freebsd.org> Message-ID: <48D3E778.3020305@elischer.org> Marko Zec wrote: > http://perforce.freebsd.org/chv.cgi?CH=150125 > > Change 150125 by zec@zec_tpx32 on 2008/09/19 17:43:14 > > curvnet is never set on entry to sysctl handlers, thus > set the vnet context via TD_TO_VNET(curthread), because > all threads must have a cred->vimage->vnet context set. it seems to me that vnet is an important enough variable that we could put it in the pcpu structure and have the scheduler set it up on context switches when vimage is compiled in. thus it would always be directly available. i.e. %gs:CURVNET_OFFSET or whatever the syntax is on x86 and the equivalent on other architectures. > > Affected files ... > > .. //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 edit > > Differences ... > > ==== //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 (text+ko) ==== > > @@ -119,7 +119,7 @@ > static int > sysctl_net_inet_tcp_mss_check(SYSCTL_HANDLER_ARGS) > { > - INIT_VNET_INET(curvnet); > + INIT_VNET_INET(TD_TO_VNET(curthread)); > int error, new; > > new = V_tcp_mssdflt; > @@ -141,7 +141,7 @@ > static int > sysctl_net_inet_tcp_mss_v6_check(SYSCTL_HANDLER_ARGS) > { > - INIT_VNET_INET6(curvnet); > + INIT_VNET_INET6(TD_TO_VNET(curthread)); > int error, new; > > new = V_tcp_v6mssdflt; From zec at freebsd.org Fri Sep 19 18:44:18 2008 From: zec at freebsd.org (Marko Zec) Date: Fri Sep 19 18:44:46 2008 Subject: vimage and curvnet. In-Reply-To: <48D3E778.3020305@elischer.org> References: <200809191743.m8JHhZj8009388@repoman.freebsd.org> <48D3E778.3020305@elischer.org> Message-ID: <200809192023.42904.zec@freebsd.org> On Friday 19 September 2008 19:55:04 Julian Elischer wrote: > Marko Zec wrote: > > http://perforce.freebsd.org/chv.cgi?CH=150125 > > > > Change 150125 by zec@zec_tpx32 on 2008/09/19 17:43:14 > > > > curvnet is never set on entry to sysctl handlers, thus > > set the vnet context via TD_TO_VNET(curthread), because > > all threads must have a cred->vimage->vnet context set. > > it seems to me that vnet is an important enough variable that we ^^^^ I guess you meant curvnet? > could put it in the pcpu structure and have the scheduler set it up > on context switches when vimage is compiled in. Right now curvnet is defined in vimage.h as #define curvnet curthread->td_vnet Note that there's also a helper field in struct thread called td_vnet_lpush aimed at tracing CURVNET_SET() stacking as well as finding places when CURVNET_RESTORE() is not called after CURVNET_SET(). Both td_vnet and td_vnet_lpush _must_ be stored with each thread anyhow, given that threads can migrate practically at any time. So, if pcpu shadowing of curthread->td_vnet could yield performace improvements than this would make sense, but we would still need to keep td_vnet as a field in struct thread, and have CURVNET_SET() and CURVNET_RESTORE() macros atomically update both the td_ field and its pcpu shadow, which would require each CURVNET_XXX() macro to include critical_enter() / _exit() invocations... > thus it would always be directly available. > i.e. %gs:CURVNET_OFFSET or whatever the syntax is on x86 > and the equivalent on other architectures. > > > Affected files ... > > > > .. //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 > > edit > > > > Differences ... > > > > ==== //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 > > (text+ko) ==== > > > > @@ -119,7 +119,7 @@ > > static int > > sysctl_net_inet_tcp_mss_check(SYSCTL_HANDLER_ARGS) > > { > > - INIT_VNET_INET(curvnet); > > + INIT_VNET_INET(TD_TO_VNET(curthread)); > > int error, new; > > > > new = V_tcp_mssdflt; > > @@ -141,7 +141,7 @@ > > static int > > sysctl_net_inet_tcp_mss_v6_check(SYSCTL_HANDLER_ARGS) > > { > > - INIT_VNET_INET6(curvnet); > > + INIT_VNET_INET6(TD_TO_VNET(curthread)); > > int error, new; > > > > new = V_tcp_v6mssdflt; From julian at elischer.org Fri Sep 19 19:36:54 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 19 19:37:07 2008 Subject: vimage and curvnet. In-Reply-To: <200809192023.42904.zec@freebsd.org> References: <200809191743.m8JHhZj8009388@repoman.freebsd.org> <48D3E778.3020305@elischer.org> <200809192023.42904.zec@freebsd.org> Message-ID: <48D3FF54.2010802@elischer.org> Marko Zec wrote: > On Friday 19 September 2008 19:55:04 Julian Elischer wrote: >> Marko Zec wrote: >>> http://perforce.freebsd.org/chv.cgi?CH=150125 >>> >>> Change 150125 by zec@zec_tpx32 on 2008/09/19 17:43:14 >>> >>> curvnet is never set on entry to sysctl handlers, thus >>> set the vnet context via TD_TO_VNET(curthread), because >>> all threads must have a cred->vimage->vnet context set. >> it seems to me that vnet is an important enough variable that we > ^^^^ > I guess you meant curvnet? > >> could put it in the pcpu structure and have the scheduler set it up >> on context switches when vimage is compiled in. > > Right now curvnet is defined in vimage.h as > > #define curvnet curthread->td_vnet > > Note that there's also a helper field in struct thread called > td_vnet_lpush aimed at tracing CURVNET_SET() stacking as well as > finding places when CURVNET_RESTORE() is not called after > CURVNET_SET(). Both td_vnet and td_vnet_lpush _must_ be stored with > each thread anyhow, given that threads can migrate practically at any > time. not without the scheduler knowing about it they can't. i.e. if the scheduler changes curvnet when it changes curthread then it will always be correct. > > So, if pcpu shadowing of curthread->td_vnet could yield performace > improvements than this would make sense, It might, and it may remove some requirements for files to include proc.h but we would still need to > keep td_vnet as a field in struct thread, and have CURVNET_SET() and > CURVNET_RESTORE() macros atomically update both the td_ field and its > pcpu shadow, which would require each CURVNET_XXX() macro to include > critical_enter() / _exit() invocations... sure, well, if a running thread has curvnet in the pcpu field and it is put back in the the thread struct on deschedule. then what in td_vnet while the thread is running is not really important. anyhow, it's just an idea. > > >> thus it would always be directly available. >> i.e. %gs:CURVNET_OFFSET or whatever the syntax is on x86 >> and the equivalent on other architectures. >> >>> Affected files ... >>> >>> .. //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 >>> edit >>> >>> Differences ... >>> >>> ==== //depot/projects/vimage-commit2/src/sys/netinet/tcp_subr.c#14 >>> (text+ko) ==== >>> >>> @@ -119,7 +119,7 @@ >>> static int >>> sysctl_net_inet_tcp_mss_check(SYSCTL_HANDLER_ARGS) >>> { >>> - INIT_VNET_INET(curvnet); >>> + INIT_VNET_INET(TD_TO_VNET(curthread)); >>> int error, new; >>> >>> new = V_tcp_mssdflt; >>> @@ -141,7 +141,7 @@ >>> static int >>> sysctl_net_inet_tcp_mss_v6_check(SYSCTL_HANDLER_ARGS) >>> { >>> - INIT_VNET_INET6(curvnet); >>> + INIT_VNET_INET6(TD_TO_VNET(curthread)); >>> int error, new; >>> >>> new = V_tcp_v6mssdflt; > From zec at freebsd.org Fri Sep 19 20:52:31 2008 From: zec at freebsd.org (Marko Zec) Date: Fri Sep 19 20:52:34 2008 Subject: vimage and curvnet. In-Reply-To: <48D3FF54.2010802@elischer.org> References: <200809191743.m8JHhZj8009388@repoman.freebsd.org> <200809192023.42904.zec@freebsd.org> <48D3FF54.2010802@elischer.org> Message-ID: <200809192252.22640.zec@freebsd.org> On Friday 19 September 2008 21:36:52 Julian Elischer wrote: .... > sure, well, if a running thread has curvnet in the pcpu field > and it is put back in the the thread struct on deschedule. > then what in td_vnet while the thread is running is not really > important. Yes this makes sense, and should be worth experimenting with. It's only that I feel reluctant to start touching anything in our scheduler(s) until all the other big changes settle in a bit first. Marko From jeffrey.m.ahrenholz at boeing.com Fri Sep 19 23:24:18 2008 From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M) Date: Fri Sep 19 23:24:22 2008 Subject: natd & vimage In-Reply-To: <48D2F9B1.8020507@elischer.org> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> <48D2F9B1.8020507@elischer.org> Message-ID: <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> > please make sure that your fixes go into the vimage branch.. > we need all the help we can get :-) I got the latest vimage branch using cvsup and was able to cleanly apply my patch, looks like nothing has changed in the divert/mroute files. Unfortunately it seems that I spoke too soon because my patch locks up on a dual-core system (I must've been testing with a non-SMP box). So I'll have to write back when I have something that actually works. Another trick, if you just want to nat between vimages, you could probably use the ng_nat netgraph node... -Jeff From julian at elischer.org Fri Sep 19 23:48:53 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 19 23:49:05 2008 Subject: natd & vimage In-Reply-To: <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> <48D2F9B1.8020507@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: <48D43A63.8080808@elischer.org> Ahrenholz, Jeffrey M wrote: >> please make sure that your fixes go into the vimage branch.. >> we need all the help we can get :-) > > I got the latest vimage branch using cvsup and was able to cleanly apply > my patch, looks like nothing has changed in the divert/mroute files. > Unfortunately it seems that I spoke too soon because my patch locks up > on a dual-core system (I must've been testing with a non-SMP box). So > I'll have to write back when I have something that actually works. > > Another trick, if you just want to nat between vimages, you could > probably use the ng_nat netgraph node... that's why netgraph is the "official" way to connect vimages :-) can you send your diffs anyhow? I never completed the virtualisation of divert. I'll see what I can do with them. > > -Jeff From jeffrey.m.ahrenholz at boeing.com Fri Sep 19 23:59:10 2008 From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M) Date: Fri Sep 19 23:59:14 2008 Subject: natd & vimage In-Reply-To: <48D43A63.8080808@elischer.org> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> <48D2F9B1.8020507@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> <48D43A63.8080808@elischer.org> Message-ID: <0DF156EE7414494187B087A3C279BDB40A94023E@XCH-NW-6V1.nw.nos.boeing.com> > can you send your diffs anyhow? > I never completed the virtualisation of divert. > I'll see what I can do with them. OK, here it is, good luck! I had divert working on a non-SMP system, could divert packets to a userspace program that touches them. Then the mroute part is a little bigger. Currently testing with XORP PIM. Known bug during system reboot it crashes during ip_mroute module unload. Haven't tested IPv6 multicast forwarding yet. (slightly off-topic/wrong list, but you can crash a 7.0-GENERIC kernel if you install the Xorp package from ports and set it up as a rendezvous point!) -Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: mroutedivert-20080908.patch Type: application/octet-stream Size: 91728 bytes Desc: mroutedivert-20080908.patch Url : http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20080919/5c234144/mroutedivert-20080908-0001.obj From julian at elischer.org Sun Sep 21 08:45:09 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Sep 21 08:45:21 2008 Subject: natd & vimage In-Reply-To: <0DF156EE7414494187B087A3C279BDB40A94023E@XCH-NW-6V1.nw.nos.boeing.com> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> <48D2F9B1.8020507@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> <48D43A63.8080808@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94023E@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: <48D6098E.3060407@elischer.org> Ahrenholz, Jeffrey M wrote: >> can you send your diffs anyhow? >> I never completed the virtualisation of divert. >> I'll see what I can do with them. > > OK, here it is, good luck! I had divert working on a non-SMP system, > could divert packets to a userspace program that touches them. > > Then the mroute part is a little bigger. Currently testing with XORP > PIM. Known bug during system reboot it crashes during ip_mroute module > unload. Haven't tested IPv6 multicast forwarding yet. (slightly > off-topic/wrong list, but you can crash a 7.0-GENERIC kernel if you > install the Xorp package from ports and set it up as a rendezvous > point!) > > -Jeff thanks! Can you tell me what version/date of FreeBSD the patches are against? It looks as if you have done a lot of work in teh mroute code which I am utterly faminiar with so hopefully this will save us a lot of time.. I did have a go at doing the divert code so it will be interesting to see the comparison... hopefully that too will be useful. From jeffrey.m.ahrenholz at boeing.com Mon Sep 29 14:38:23 2008 From: jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M) Date: Mon Sep 29 14:38:29 2008 Subject: natd & vimage In-Reply-To: <48D6098E.3060407@elischer.org> References: <0DF156EE7414494187B087A3C279BDB40A93F94B@XCH-NW-6V1.nw.nos.boeing.com> <48D2F9B1.8020507@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94021D@XCH-NW-6V1.nw.nos.boeing.com> <48D43A63.8080808@elischer.org> <0DF156EE7414494187B087A3C279BDB40A94023E@XCH-NW-6V1.nw.nos.boeing.com> <48D6098E.3060407@elischer.org> Message-ID: <0DF156EE7414494187B087A3C279BDB40AA38284@XCH-NW-6V1.nw.nos.boeing.com> > Can you tell me what version/date of FreeBSD the patches are against? The patches are against the vimage_7-20080228 kernel (from http://imunes.tel.fer.hr/virtnet/); also, I think that it applied cleanly to vimage kernel pulled using cvsup on 2008-09-19. -Jeff