WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] domain creation

To: Assem Bsoul <asem.bsoul@xxxxxxxxx>
Subject: Re: [Xen-devel] domain creation
From: Daniel Stodden <stodden@xxxxxxxxxx>
Date: Wed, 24 Oct 2007 01:48:10 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 23 Oct 2007 16:48:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <eb467b720710231128w3e5f1afft9b1d84f54b4b95d5@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fakultät für Informatik I10, Technische Universität Münche
References: <eb467b720710231128w3e5f1afft9b1d84f54b4b95d5@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2007-10-23 at 14:28 -0400, Assem Bsoul wrote:
> Hi,
> 
> I am reading the source code for Xen, specifically the scheduler code.
> Now I am trying to figure out how the vcpus are created for the
> domain, because when I came to the function alloc_idle_vcpu() in
> common/domain.c, I found that it has calls to the domain_create() and
> alloc_vcpu() functions, which made me confused. 

this routine is only called by bootcode.

basics you might already be aware of: a virtual machine is mostly a
struct domain. a struct domain comprises multiple vcpus. might be one
per domain. might be as many as there are physical cpus in the system.
might be even more, but thats rarely of practical use. a vcpu is what
gets mapped (arbitrarily chosen, unless you 'pin' it) to a cpu when the
domain is running. regarding smp, it is similar to what a kernel thread
is to a process, if you consider schedulers, but there are certainly
differences, so be careful with analogies).

there are a number of special domains. one is the 'idle' domain, i.e.
the domain left when no other vcpu is runnable (e.g. blocking, paused,
see def. vcpu_runnable() ). 

the difference between the idle and a regular vcpu is best explained by
looking at continue_nonidle_domain() and continue_idle_domain(). both
functions represent either path taken by schedule() -> context_switch()
-> schedule_tail(), i.e. the path a regular vcpu would take back into
the guest system when it is scheduled.

regarding domain creation:
- dom0 is special in may ways.
  it gets created from bootcode, and it typically gets one vcpu per 
  physical cpu right from the start.
- the idle domain is created in in init_idle_domain() during boot.
  remember, booting is done on a single cpu.
  the idle domain is therefore initialized with a single idle vcpu.
  smp initialization comes later, this is where
  alloc_idle_vcpu() is called: as soon as the additional smp processors
  are initialized.
- regular domains: domain creation and vcpu creation go separate.
  i suppose that is what confused you.
  the control libraries first create the domain (via a domctl
  see include/public/domctl.h and do_domctl() in the xen source).
  then they add the desired number of vcpus to the domain. look
  for XEN_DOMCTL_max_vcpus. none will won't run before the domain is
  unpaused, which is after finishing domain creation, lots of which is 
  done not in the hypervisor but in userland on dom0.

hth,
daniel

> Please post some information if you have an idea about what is going
> there for vcpu creation. Details are highly appreciated. 
> 
> Thanks
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>