PERFORCE change 145189 for review
julian at FreeBSD.org
Mon Jul 14 05:08:36 UTC 2008
Change 145189 by julian at 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
==== //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.
- * 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
(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
More information about the p4-projects