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>
- Fixed type of variables in hypervisor.c.
- Fixed not removing a waiter from watch_queue.
- Make wait_for_watch() global accessible.
Signed-off-by: Dietmar Hahn <dietmar.hahn@fujitsu-siemens.com>
The arguments to this macro didn't have parentheses around them where
they were used. If a call to a TRACE macro included an expression as
an argument, the cast to (unsigned long) could bind to just part of
the expression and lead to unexpected results.
Signed-off-by: Michael Vrable <mvrable@cs.ucsd.edu>
The HVM guest did not respond when PV-on-HVM driver was tested on
the following conditions.
1. RHEL4u4
2. vcpu 4
3. irqbalance on
4. pv-on-hvm driver used.
Eventhandler did not work because IRQ was delivered to another vcpu by
irqbalance.
Signed-off-by: Tsunehisa Doi <Doi.Tsunehisa@jp.fujitsu.com>
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
implementation is broken until Python v2.4.3. Instead cast the C value
to long long and use the 'L' specifier.
Signed-off-by: Keir Fraser <keir@xensource.com>
- gcc-3.2 cannot handle some multi-line assertions in the Xen
sources. Noone noticed.
- gcc-3.3 has problems with alignment constraints inside typedefs.
gcc 3.4.0 is now three years old so I hope that everyone has an
up-to-date compiler, or can obtain a more up-to-date package for their
distribution. If not we may need to fall back to supporting gcc-3.3.x
as well.
Also clean up the way we do version checks, using the power of awk.
Signed-off-by: Keir Fraser <keir@xensource.com>