From owner-p4-projects@FreeBSD.ORG Mon Jul 14 05:08:36 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 695DD1065671; Mon, 14 Jul 2008 05:08:36 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CF87106566B for ; Mon, 14 Jul 2008 05:08:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8F78FC0C for ; Mon, 14 Jul 2008 05:08:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m6E58aBH035879 for ; Mon, 14 Jul 2008 05:08:36 GMT (envelope-from julian@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.2/8.14.1/Submit) id m6E58KSm035868 for perforce@freebsd.org; Mon, 14 Jul 2008 05:08:20 GMT (envelope-from julian@freebsd.org) Date: Mon, 14 Jul 2008 05:08:20 GMT Message-Id: <200807140508.m6E58KSm035868@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to julian@freebsd.org using -f From: Julian Elischer To: Perforce Change Reviews Cc: Subject: PERFORCE change 145189 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2008 05:08:36 -0000 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