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] [PATCH 1/2][RESEND] xend: fix vcpu related items

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/2][RESEND] xend: fix vcpu related items
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Wed, 9 Nov 2005 10:21:11 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 Nov 2005 16:21:24 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20051109142247.GL15954@xxxxxxxxxxxxxxxxxxxxxx>
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>
References: <20051108232132.GA1858@xxxxxxxxxx> <20051109142247.GL15954@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
* Ewan Mellor <ewan@xxxxxxxxxxxxx> [2005-11-09 08:23]:
> On Tue, Nov 08, 2005 at 05:21:32PM -0600, Ryan Harper wrote:
> 
> > Resending, rediffed against changeset: 7701:abbe3df33774
> 
> Thanks for your resends, Ryan.  Your two patches are in my tree at the moment,
> and I'm testing them.

Great!

> 
> There are now so many fields with "cpu" in the name that I was looking over it
> wondering if there were a few we could lose now.  Perhaps we could review them
> on the list.

Yeah, as I was wading through this I was thinking the same thing.

> 
> I count
> 
> vcpus         the number of virtual CPUs this domain is configured to use.
> vcpu_avail    VCPU availability bitmap
> vcpu_count    same as vcpus, just in the getVCPUInfo sxpr
> cpumap        VCPU-to-CPU bitmap list
> cpu           configuration pinning VCPU 0 to the specified physical CPU
> max_vcpu_id
> online_vcpus
> 
> as well as the obvious
> 
> cpu_time
> cpu_weight
> 
> So could you explain the semantics of max_vcpu_id and online_vcpus, compared
> with vcpus and vcpu_avail in particular?  I'm afraid I've lost track.

'max_vcpu_id' is the highest id of a vcpu that has been
created/initialized.  So, for instance, after booting dom0 SMP on a 4
way, the hypervisor's domain builder creates one VCPU for each physical
cpu leaving max_vcpu_id=3.

'online_vcpus' is a count of the number of vcpus that can be scheduled in
a domain (they are runnable, that is VCPUF_down is not set, which
happens when we disable/unplug vcpus).

'vcpus' is the value parsed from a domain's config file, ie, the number of
vcpus you want your domain to have.  

'vcpu_avail' is a bitmap (probably should convert it to a list since we
have been tossing the C-ism out) indicating which vcpus are available
(runnable, enabled, etc.).  Currently, vcpu_avail is derived from 
'vcpus', (vcpu_avail = (1 << vcpus) - 1) and assumes that all possible
vcpus are available.

In some cases, we don't have a configuration file which would have the
'vcpus' element (dom0 is one such example).  Such domains are usually
running prior to starting xend in which case the info dict
returned from xc_domain_getinfo contains the run-time variables
'online_vcpus' and 'max_vcpu_id'.  We can use those values to calculate
vcpu_avail.

Actually, rather that using max_vcpu_id+1 to calculate vcpu_avail for
running domains as I did in my patch we should build it with a loop
check each vcpu if it is up or not:

for v in range(0,info['max_vcpu_id']+1):
   vinfo = xc.vcpu_getinfo(domid,v)
   if vinfo['online']:
      vcpu_avail |= 1 << v


One of the difficulties we have is that is is not always clear in the
code where we want configuration information (ie, how many vcpus did you
want your domain to have) or runtime info (which vcpus in this domain
are online right now).  I think vcpu_count is just one of those cases,
one could want access to either type but we only have one method
and if you are not aware of what that means, then we are possibly
introducing bugs.

Personally I'd like to see a separate dict for config and runtime info

config = parseConfig(c)  # only filled with values from config file
info   = dom_get(domid)  # current runtime info as returned from HV

Possibly too late in the game for this sort of rework.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx

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