VCPUs_at_startup. Add VM.set_VCPUs_number_live, VM.add_to_VCPUs_params_live,
VM_metrics.VCPUs_{CPU,flags,params}.
Use these new calls to implement xm vcpu-list and xm sched-credit through
the Xen-API. Mark a number of other calls as unimplemented through that API.
Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
Signed-off-by: Ewan Mellor <ewan@xensource.com>
It is no longer being maintained and probably shouldn't have existed in the
first place, since it was almost identical to xc_linux_build.c.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
it. This avoids a race so that you don't lose messages, matches the behaviour
of the hypercall, and the Unix dmesg command.
Change the Xen-API binding to use a separate function host.dmesg_clear rather
than a flag on host.dmesg.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Using the GPF handler to spot the software interrupt and pass it back
to the guest increases the base syscall time by a factor of 2.7
compared with 32on32 using direct trap to ring 1. (0.3270->0.8680
microseconds, measured with lmbench lat_syscall).
Since the 64 bit IDT can only contain 64 bit segment selectors we
cannot trap directly to compat mode ring 1. However implementing a
dedicated 64 bit ring 0 trap handler allows us to avoid much of the
GPF handler overhead and reduces the overhead to 1.7 times
(0.3270->0.5497 microseconds).
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Currently, we mount all blktap disks for pygrub so that it can boot
from e.g. QCOW images. However, since pygrub will handle a raw image
just fine without mounting through blktap, we shouldn't bother in that
case.
Also, it looks like XendDomainInfo.create_vbd() takes the full disk
uname rather than the image path.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Instead of kludging a max_gpfn estimate in shared_info, add a new
XENMEM command to discover the actual maximum gpfn value as known by
the shadow code.
This needs to be more robust when we support HVM ballooning in future
anyway. One interesting point is that max_gpfn may be close to 4GB
even for small-memory HVM guests since for example SVGA LFB is mapped
into the I/O hole. We may need to special case the I/O hole somehow,
or provide some finer-grained way to find out which parts of the GPFN
space are actually used (e.g., get Xen to fill in a bitmap with 1 bit
per 1024 pages, or similar).
Signed-off-by: Keir Fraser <keir@xensource.com>
and into the earlier AP bringup code. This stops it from resetting
the VCPUs of SMP guests into real mode on restore or migrate.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
The frequency of HPET device model is defined to be the same as TSC's,
but this doesn't work well with calibrate_tsc_hpet() in Linux kernel
2.6.16-33, causing some IA32 Linux HVM guests to failt o boot.
Calibrate_tsc_hpet() tries to figure out how many HPET ticks a TSC
cycle equals; it magnifies the result by scale of 2^32, trying to get
a more accurate result since it assumes the frequency of HPET in real
world is usually less than 1/100 of TSC, so the result of "(2^32 *
hpet_freq) / tsc_freq" may exceed 32bits, then a "divide error
(overflow)" would occur!
The result doesn't overflow every time because hpet_freq/tsc_freq may
less than 1.0 due to the little inaccuracy in the implementation of
HVM timer virtualization.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Ewan Mellor
Ian Campbell
kfraser@localhost.localdomain
Hollis Blanchard
Tim Deegan
Mark McLoughlin
Christian Limpach