Re: RFC: Enabling VIMAGE in GENERIC
On 19.11.2014 07:28, Craig Rodrigues wrote:
On Mon, Nov 17, 2014 at 9:47 AM, Alfred Perlstein
wrote:
On 11/17/14, 3:02 AM, Warner Losh wrote:
On Nov 17, 2014, at 12:46 AM, Craig Rodrigues
wrote:
(3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO
and
https://bugs.freebsd.org/bugzilla/buglist.cgi?
quicksearch=vimage%20or%20vnet
and try to clean things up. Get help from net@ developers to
do
this.
And if these don't get cleaned up?
If they are not cleaned/stable up by 11-RELEASE then we turn it off. That
is simple.
Yes, I agree with Alfred that we can turn VIMAGE back off before
11-RELEASE if things don't get cleaned up.
We have approximately until the end of 2015, so that gives
us time.
(4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from
the ipfilter maintainers for this and some net@ developers.
And if this doesn't happen?
Well we do have 2 other firewalls in the kernel to pick, but we do need
VIMAGE so I will let you draw your own conclusions.
Again, I agree with Alfred on this. Darren Reed originally imported
ipfilter into FreeBSD, but hasn't actively maintained it (in FreeBSD) in a
while. Cy Schubert has recently expressed interest in ipfilter and has
committed some fixes in the past year, but has not fixed the VIMAGE problems
( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176992 ).
I can take an initial effort at trying to fix VIMAGE + ipfilter.
In the past, I've delved into areas I'm not so familiar with in
order to fix VIMAGE + Bluetooth. If Cy can provide any knowledge or
guidance, that will be great.
A lot of bug fixes have gone into VIMAGE in the past 2 years,
and I have received multiple reports of people using it in production
environments. See the latest post by Peter Ross.
To flush out the last few issues and corner cases, I think we
need to turn VIMAGE on by default and get feedback and help from
the FreeBSD user community and developers to identify and fix the problems.
Can we have some wiki/man/docs on how particular subsystem should
interact with VNET first?
This can probably help to make proper vnet fixes in less number of
attempts :)
For example, even attach/detach is handled differently in different places:
tcp_subr.c:
/* Skip initialization of globals for non-default instances. */
if (!IS_DEFAULT_VNET(curvnet))
return;
in6_rmx.c:
/*
* Initialize our routing tree.
*/
static VNET_DEFINE(int, _in6_rt_was_here);
#define V__in6_rt_was_here VNET(_in6_rt_was_here)
if (V__in6_rtwas_here == 0) {
callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
in6_mtutimo(curvnet); /* kick off timeout first time */
V__in6_rt_was_here = 1;
}
return (1);
}
It would be great to get a bit more details on the following (at least
from my point of view):
* what is the proper procedure of handling non-default VNET
attach/detach (locking mostly)
* how can one properly cache needed VNET context (e.g. is it safe just
to save "struct vnet *" pointer) and is this right thing to do at all?
* Is it safe to to CURVNET_SET without holding any VNET locks ?
P.S. I'm not against VIMAGE in any kind, I think we really should move
forward towards making it stable.
However, "just turn it on" concept with a bunch of known (and unresolved
issues) is not the best thing IMO.
We have about 1 year until 11-RELEASE, so I think it is OK to do this.
I would also add two items to my action plan.
(6) Ask clusteradm to run one of the machines they use
for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide
feedback.
(7) Ask for help with testing from companies who have more involvement
with the network stack. Two of the people in the CC: line of this
e-mail work for such places. :)
--
Craig
--
Craig
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
Re: RFC: Enabling VIMAGE in GENERIC
On Wed, 19 Nov 2014 16:07:46 +0400
"Alexander V. Chernikov" wrote:
...
> Can we have some wiki/man/docs on how particular subsystem should
> interact with VNET first?
> This can probably help to make proper vnet fixes in less number of
> attempts :)
>
> For example, even attach/detach is handled differently in different
> places:
>
> tcp_subr.c:
> /* Skip initialization of globals for non-default instances.
> */ if (!IS_DEFAULT_VNET(curvnet))
> return;
> in6_rmx.c:
> /*
> * Initialize our routing tree.
> */
> static VNET_DEFINE(int, _in6_rt_was_here);
> #define V__in6_rt_was_here VNET(_in6_rt_was_here)
>
> if (V__in6_rtwas_here == 0) {
> callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
> in6_mtutimo(curvnet); /* kick off timeout first
> time */ V__in6_rt_was_here = 1;
> }
>
> return (1);
> }
>
> It would be great to get a bit more details on the following (at
> least from my point of view):
> * what is the proper procedure of handling non-default VNET
> attach/detach (locking mostly)
In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to
invoke per-subsystem ctors / dtors on per-vnet basis.
> * how can one properly cache needed VNET context (e.g. is it safe
> just to save "struct vnet *" pointer) and is this right thing to do
> at all?
Caching a VNET context should be avoided, as it yields similar problems
as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs
which may disappear by the time the mbuf gets dequeued.
> * Is it safe to to CURVNET_SET without holding any VNET locks ?
Yes, if the VNET context is derived from some of the arguments in the
current call graph.
> P.S. I'm not against VIMAGE in any kind, I think we really should
> move forward towards making it stable.
> However, "just turn it on" concept with a bunch of known (and
> unresolved issues) is not the best thing IMO.
> >
> > We have about 1 year until 11-RELEASE, so I think it is OK to do
> > this.
> >
> > I would also add two items to my action plan.
> >
> >
> > (6) Ask clusteradm to run one of the machines they use
> >for PF firewalls + IPv6 with a VIMAGE enabled kernel, and
> > provide feedback.
> >
> > (7) Ask for help with testing from companies who have more
> > involvement with the network stack. Two of the people in the CC:
> > line of this e-mail work for such places. :)
> >
> > --
> > Craig
> >
> >
> > --
> > Craig
> > ___
> > freebsd-...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to
> > "freebsd-net-unsubscr...@freebsd.org"
> >
>
> ___
> freebsd-virtualization@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscr...@freebsd.org"
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
Re: RFC: Enabling VIMAGE in GENERIC
On 19 Nov 2014, at 03:28 , Craig Rodrigues wrote: > > (6) Ask clusteradm to run one of the machines they use > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and provide > feedback. For people to use pf with VIMAGE we first MUST have the security fix imported that I pointed out a couple of times in the past. It won’t matter on the firewalls with just a VIMAGE enabled kernel but using VIMAGE + pf inside a jail (once that really works if it doesn’t already) will allow everyone how can administer pf inside the jail to take over the entire machine otherwise. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: RFC: Enabling VIMAGE in GENERIC
Alexander V. Chernikov wrote this message on Wed, Nov 19, 2014 at 16:07 +0400: > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? Yes, we need a man page talking about this feature first, how to enable it, compile it into the kernel, how to manage it, what subsystems it interacts w/, what sysctl nodes it provides, etc. W/o man page(s) the feature is not complete. $ man -k vnet revnetgroup(8) - generate reverse netgroup data $ man -k vimage XvCreateImage(3), XvShmCreateImage(3) - create an XvImage XvPutImage(3), XvShmPutImage(3) - display an XvImage hmm.. nope... jail has something about vnets, but not nearly enough to be useful... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: Trying to run an older head in a recent Bhyve.
On 16-11-2014 19:19, Allan Jude wrote: > On 2014-11-16 12:54, Willem Jan Withagen wrote: >> On 16-11-2014 0:59, Peter Grehan wrote: >>> Hi Willem, >>> I'm trying to run one of my older VM's and get the crash below in the VM when trying to boot... This happens both on an older BSD: FreeBSD 11.0-CURRENT (FREETEST) #1 r273066M: Sun Oct 19 00:59:06 CEST 2014 As well as on a very recent: FreeBSD 11.0-CURRENT (BHYVE00) #0 r274490M: Fri Nov 14 02:42:43 CET 2014 The older 10.0 VM's do boot normally Any suggestions on what this might be, and/or how to debug this.. >>> >>> Did the disk image backing file change by any chance ? e.g. from file >>> to zvol ? >>> >>> What's the version of the VM that has the issue ? >> >> Not sure what you mean by that exactely, but the VM runs a relatively >> old HEAD: >> >> FreeBSD 11.0-CURRENT #1 r262690: Sun Mar 2 21:28:19 CET 2014 >> root@bhyve-head:/usr/obj/usr/src/sys/GENERIC amd64 >> >> It boots in single mode. >> >> I'tt try and manually assign an IP number and will see what that brings. > He is asking how the virtual disk is setup, specifically, if it is a zvol > > Judging by the backtrace, the VM is panicing when trying to write to the > disk and it fails > > From my experience, the two most likely causes are: > > 1) The disk is a zvol, and does not have the volmode set, and GEOM on > the host is grabbing the disk and locking it, preventing writes > > 2) The VM was shutdown ungracefully and the file system needs a fsck. > Since you can get into single user mode, this should be doable. The VM-disk is a file, very early on I tried things with ZVOL but have not yet returned to testing those. Well the system passes the fsck-check during boot. And I can manually config the network, and /etc/resolv.conf Then the system stays up, and I was able to download the new sources and build them without crashing the system... I really crashed right after DHCP answers --WjW ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: RFC: Enabling VIMAGE in GENERIC
On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney wrote: > > Yes, we need a man page talking about this feature first, how to enable > it, compile it into the kernel, how to manage it, what subsystems it > interacts w/, what sysctl nodes it provides, etc. > Marko, Do you have any text which can be put into a vnet(9) man page? It doesn't have to be perfect, but just something that we can start from. I tried looking at some of the notes and presentations that you have done on VIMAGE: https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles but didn't see anything that could be readily turned into a man page. -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: RFC: Enabling VIMAGE in GENERIC
On 19 Nov 2014, at 23:14 , Craig Rodrigues wrote: > On Wed, Nov 19, 2014 at 11:59 AM, John-Mark Gurney wrote: > >> >> Yes, we need a man page talking about this feature first, how to enable >> it, compile it into the kernel, how to manage it, what subsystems it >> interacts w/, what sysctl nodes it provides, etc. >> > > Marko, > > Do you have any text which can be put into a vnet(9) man page? > It doesn't have to be perfect, but just something that we can start from. > > I tried looking at some of the notes and presentations that you have done > on VIMAGE: > https://wiki.freebsd.org/?action=fullsearch&context=180&value=VIMAGE&titlesearch=Titles > > but didn’t see anything that could be readily turned into a man page. https://people.freebsd.org/~bz/20100530-02.vnet.9.html The man page should be in that perforce branch you converted to github. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
'repz' instruction not supported.
Hi We have found that emulation of 'repz' instruction is not supported in bhyve. This is causing VM_EXIT for Guest OS. Do we have plans to add support for instructions like 'repz'. RegardsAshutosh ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
How to update bhyve (supporting amd) from freebsd-10.1
Hi! I know, that bhyve support AMD processors from version r273375.. I have processor, that support RVI and Freebsd-10.1 (release). So.. How to update (patch/rebuild/something else) bhyve to r2773375 on my fresh freebsd 10.1? Is it possible? I just want to install several virtual freebsd )) -- With respect, Ilya ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
