[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2][RESEND] xend: fix vcpu related items
* 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |