Date: Mon, 14 Jul 2008 05:08:20 GMT From: Julian Elischer <julian@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 145189 for review Message-ID: <200807140508.m6E58KSm035868@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=145189 Change 145189 by julian@julian_trafmon1 on 2008/07/14 05:07:45 Slight cleanups after talking with Marko. Affected files ... .. //depot/projects/vimage/porting_to_vimage.txt#4 edit Differences ... ==== //depot/projects/vimage/porting_to_vimage.txt#4 (text+ko) ==== @@ -14,25 +14,42 @@ This generally requires NO changes to the network drivers of the classes covered (e.g. ethernet). -2/ If the module is to be virtualised, decide which attributes of the - module shoudl be virtualised. +2/ decide if your module is part of one of the major module groups. + These are V_GLOBAL V_NET V_PROCG V_CPU. + + The reader will note that the descriptions below use the acronym VNET + a lot. The vimage system has been at this time broken into a number of + subsections. One of these is the "VNET" group. The idea of these + subsections is that they might be individually selected as + virtualizable in a particular virtual machine instance. + + As an example, in a virtualization, one might to allocate a couple of + processors to it, but keep the saem filesystem and network setup, or + alternatively to share processors but to have virtualised networking. + + The current code has a "vnet" pointer in the thread. It could be argued + that it should actually be a vimage. + + [comments from Marko here] + +3/ If the module is to be virtualised, decide which attributes of the + module should be virtualised. - For example, It may make sense that ther ebe a single central pool + For example, It may make sense that there be a single central pool of "struct foo" and a single uma zone for them to come from, with a single - lock guarding it. it might also make sense if the "foo_debug" sysctl + lock guarding it. It might also make sense if the "foo_debug" sysctl controls all the instances at once, while on the other hand, the "foo_mode" sysctl might make better sense if it were controllable on a virtual system by virtual system basis. -3/ Work out what global variables and structures are to be virtualised to +4/ Work out what global variables and structures are to be virtualised to achieve the behaviour required for part #2. - -4/ Work out for all the code paths through the module, how the path entering +5/ Work out for all the code paths through the module, how the path entering the module can divine which virtual machine it is on. Some examples: - * Since interfaces are all assighed to one virtual machine or + * Since interfaces are all assigned to one virtual machine or another, an incoming packet has a pointer to the receive interface, which in turn has a pointer to the virtual machine instance. * Similarly, on any request from outside the kernel, (direct or indirect) @@ -51,13 +68,12 @@ required for the module to stash away the virtual machine instance somewhere, and make associated changes in the code. -5/ Add the code described below to the files that make up the module - +6/ Add the code described below to the files that make up the module - Details: (temp. for module FOO add a definition for VNET_MOD_FOO in sys/vimage.h) +For now these instructions refer mainly to VNET and not VCPU etc. Symbols defined in other modules that have been virtualised will have been moved to a module-specific virtualisation structure. It will be defined in a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807140508.m6E58KSm035868>