In specific, it fixes the following issues:
1. The sub-leaves of CPUID:0x0000000D aren't contiguous. Hypervisor
shouldn't use register values to stop the enumeration. This patch
moves checking on XSAVE sub-leaves out of if-else statement. It also
bumps up sub-leaves to 63.
2. It creates a common function for xsave.
3. The main leaf 0 of CPUID:0x0000000D in current Xen is broken,
especially ECX and EBX registers. This patch cleans it up.
4. It adds support to detects EBX value of CPUID:0x0000000D main leaf
0 on-the-fly.
Signed-off-by: Wei Huang2 <wei.huang2@amd.com>
Allow the "unbalance tolerance" -- the amount of difference between
two runqueues that will be allowed before rebalancing -- to differ
depending on how busy the runqueue is. If it's less than 100%,
default to a difference of 1.0; if it's more than 100%, default to a
tolerance of 0.125.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
This is a first-cut at getting load balancing. I'm first working on
looking at behavior I want to get correct; then, once I know what kind
of behavior works well, then I'll work on getting it efficient.
The general idea is when balancing runqueues, look for the runqueue
whose loadavg is the most different from ours (higher or lower).
Then, look for a transaction which will bring the loads closest
together: either pushing a vcpu, pulling a vcpu, or swapping them.
Use the per-vcpu load to calculate the expected load after the
exchange.
The current algorithm looks at every combination, which is O(N^2).
That's not going to be suitable for workloads with large numbers of
vcpus (such as highly consolidated VDI deployments). I'll make a more
efficient algorithm once I've experimented and determined what I think
is the best load-balancing behavior.
At the moment, balance from a runqueue every time the credit resets.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Put in infrastructure to allow a vcpu to requeset to migrate to a
specific runqueue. This will allow a load balancer to choose running
VMs to migrate, and know they will go where expected when the VM is
descheduled.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
As vcpus are migrated, track how we expect the load to change. This
helps smooth migrations when the balancing doesn't take immediate
effect on the load average. In theory, if vcpu activity remains
constant, then the measured avgload should converge to the balanced
avgload.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Track the amount of load contributed by a particular vcpu, to help
us make informed decisions about what will happen if we make a move.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Because alloc_pdata() is called before the cpu layout information is
available, we grab a callback to the newly-created CPU_STARTING
notifier.
cpu 0 doesn't get a callback, so we simply hard-code it to runqueue 0.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
In preparation for multiple runqueues, add a simple cpu picker that
will look for
the runqueue with the lowest instantaneous load to assign the vcpu to.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Add hooks in the various places to detect vcpus becoming active or
inactive. At the moment, record only instantaneous runqueue load;
but this lays the groundwork for having a load average.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
In preparation for cross-runqueue migration, make changes to make that
more robust.
Changes include:
* An up-pointer from the svc struct to the runqueue it's assigned to
* Explicit runqueue assign/desassings, with appropriate ASSERTs
* cpu_pick will de-assign a vcpu from a runqueue if it's migrating,
and wake will re-assign it
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Several refactorizations:
* Add prv->initialized cpu mask
* Replace prv->runq_count with active_queue mask
* Replace rqd->cpu_min,cpu_mask with active cpu mask
* Put locks in the runqueue structure, rather than borrowing the
existing cpu locks
* init() initializes all runqueues to NULL, inactive, and maps all
pcpus to runqueue -q
* alloc_pcpu() will add cpus to runqueues, "activating" the runqueue
if necessary. All cpus are currently assigned to runqueue 0.
End-to-end behavior of the system should remain largely the same.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Many places in Xen, particularly schedule.c, grab the per-cpu spinlock
directly, rather than through vcpu_schedule_lock(). Since the lock
pointer may change between the time it's read and the time the lock is
successfully acquired, we need to check after acquiring the lock to
make sure that the pcpu's lock hasn't changed, due to cpu
initialization or cpupool activity.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Credit2 has different cpus share a lock; which means that as cpus are
added, and as they're moved between pools, the pointer to the
scheduler lock may also change as well.
Since we don't want to have to grab a lock before grabbing the per-cpu
scheduler lock, we use the lock itself to protect against the pointer
changing.
However, since it may change between reading and locking, after we
grab the lock we need to check to make sure it's still the right one.
Update the vcpu_schedule_lock() definition to reflect this: both
v->processor and that processor's schedule lock are liable to change;
check both after grabbing the lock, and release / re-acquire if
necessary.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
New xl command cpupool-numa-split which will create one cpupool for each
numa node of the machine. Can be called only if no other cpupools than Pool 0
are defined. After creation the cpupools can be managed as usual.
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Add a new library function libxl_cpupool_rename() and a new xl command
xl cpupool-rename to support renaming of cpupools.
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
The user interfaces for cpupools are extended to support numa machines:
- xl cpupool-create supports now specifying a node list instead of a cpu list.
The new cpupool will be created with all free cpus of the specified numa
nodes.
- xl cpupool-cpu-remove and xl cpupool-cpu-add can take a node number instead
of a cpu number. Using 'node:1' for the cpu parameter will, depending on
the operation, either remove all cpus of node 1 in the specified cpupool,
or add all free cpus of node 1 to the cpupool.
libxl is extended with the following functions to support this feature:
int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Adds option -n/--numa to xl info command to print topology information.
No numa information up to now, as I've no machine which will give this info
via xm info (could be a bug in xm, however).
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Added new function libxl_get_topologyinfo() to obtain this information from
hypervisor.
Signed-off-by: juergen.gross@ts.fujitsu.com
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
This helps ensure that the osdep abstraction is complete by
allowing us to avoid including xc_private.h.
All the other OS backends could benefit from the same treatment but
since I cannot compile test I did not do this.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Now that this file exists it is a better home for these than xc_misc.c
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Add a dummy backend which always returns ENOSYS. Mainly as a compile
time testbed rather than because it is a useful backend.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
Transition to xc_osdep_handle is now complete and nothing uses
(or should be using) it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
i.e. not running on a real hypervisor
Allows users of the library to adjust behaviour. I don't especially
like this violation of the abstraction but both oxenstored and xapi
use this to avoid difficult to simulate operations when running on the
simulator.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
do_privcmd() was only ever used by do_xen_hypercall() so remove it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
This patch introduces the basic infrastructure and uses it for open
and close operations on privcmd, evtchn and gnttab devices.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson.citrix.com>
The xc_interface previously passed to xc_gnttab_* was only used for
logging which can now be done via the xc_gnttab handle instead.
This makes the interface consistent with the changes made to the main
interface in 21483:779c0ef9682c.
Also update QEMU_TAG to pull in the corresponding qemu change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This makes the interface consistent with the changes made to the main
interface in 21483:779c0ef9682c.
Also fix some references to "struct xc_interface" which should have
been simply "xc_interface" in tools/xenpaging, and update QEMU_TAG to
pull in the corresponding qemu change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
They simply make hypercalls and perform other operations via the
abstract interface. Create xc_gnttab.c and move those functions there.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Since 22187:c41252a55a0a we have been installing our example
xencommons settings file in either /etc/sysconfig or /etc/default,
depending on whether /etc/sysconfig exists.
However I omitted to add the code to /etc/init.d/xencommons to
actually read either version of the file, although every other init
script seems to have it.
An effect of this misplaced/unread file is that the automatic tests
don't cause xenconsoled to collect serial logs, because the tester
edits whichever file actually exists.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser
Juergen Gross
Ian Campbell
Ian Jackson