This patch defines ia64 xc_hvm_build_target_mem() which
is referenced by xc.c.
Without this patch, xend doesn't boot complaining
that symbol, xc_hvm_build_target_mem, is missing.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
This patch fixes the following compilation error caused by
18963:9cc632cc6d40 of xen-unstable.hg
> xenctx.c: In function 'print_ctx':
> xenctx.c:430: error: request for member 'c' in something not a structure or union
> xenctx.c:431: error: 'vcpu_guest_context_any_t' has no member named 'regs'
> xenctx.c:484: error: 'vcpu_guest_context_any_t' has no member named 'event_callback_ip'
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
I have copied the tarballs that the xen-unstable build downloads to
xenbits.xensource.com (which also hosts our hg and git). This patch
changes the download URLs to use that location.
That way the build will depend on only one external machine, under one
administration, rather than many. Also it means that the build won't
break if these sites become permanently unavailable or are rearranged
and we don't run a risk of having to panic and beg if a file should go
missing.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
When we statically assign a pci device (the pci=3D['xx:xx.x'] string
in guest config file) to guest, we make many checkings (for instance,
if the device is specified in 'pciback.hide', if it has
non-page-aligned MMIO BARs, if it has a proper FLR capability, if the
related devices should be co-assigned). However, with respect to the
guest hotplug, we only check if the device exists and not assigned yet
-- this is not enough, for instance, now xend allows us to assign an
in-use device (being used by Dom0) to an HVM guest (because
xc.test_assigned() returns OK) -- this will cause disaster... The
patch adds some necessary checkings.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Add support to xenctx for guests that have a different word size
to the tools (x86 only, but shouldn't break ia64). Again, only 32-bit
HVM guests are supported until EFER.LMA is easier to get at.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
(32-bit) HVM guests. 64-bit HVM guests are still not supported for
now, pending a sensible way of getting at the guest's EFER.LMA.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Xend integration for PoD functionality.
* Add python bindings for xc_hvm_domain_build() and
xc_domain_memory_set_pod_target()
* Always call xc_hvm_domain_build(), with memsize = memory_static_max
and target=memory_dynamic_max
* When setting a new memory target:
+ First make sure we actually have enough free memory for the target
setting to succeed
+ Call set_pod_target() with the new target, to Xen can do the Right
Thing.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Implement libxc interface to PoD functionality:
* Add xc_hvm_build_target_mem(), which takes both memsize and target.
Memsize is the total memory, allocated in PoD pages and reported in
the e820; target is the size of the cache. If these are the same, the
normal funcitonality is called. (So you can use the same function to
build always, and it will decide whether to use PoD or not.)
* Add xc_domain_memory_[gs]et_pod_target(), which sets and/or returns
information about the PoD cache and p2m entries.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
ia64 linux 2.6.18 only use ar.itc for local ticks so that
ar.itc didn't need paravirtualization and it can be work arounded
when save/restore.
However recent ia64 linux uses ar.itc for sched_clock() and
CONFIG_VIRT_CPU_ACCOUNTING and other issues. So ar.itc needs
paravirtualization. Although Most part is done in guest OS,
save/restore needs hypervisor support.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
In DSDT, reserve the IO port ranges: [0x10c0, 0x10c2] and [0xb044,
0xb047] that are used by the virtual PCI hotplug.
Or else, for a hotplugged-in device, the port IO BAR assigned by guest
OS may conflict with the ranges here.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
this means that in some cases it cannot be owner of its own xenstore
nodes.
This bug was pointed out by Daniel Berrange at Red Hat. This patch is
my own more generic fix that automatically covers a range of callers
(albeit the patch is arguably a bit of a hack ;-).
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
tune the parameters manually.
Now, xenpm can be invoked with the following options:
Usage:
xenpm get-cpuidle-states [cpuid]: list cpu idle information on
CPU cpuid or all CPUs.
xenpm get-cpufreq-states [cpuid]: list cpu frequency
information on CPU cpuid or all CPUs.
xenpm get-cpufreq-para [cpuid]: list cpu frequency information
on CPU cpuid or all CPUs.
xenpm set-scaling-maxfreq <cpuid> <HZ>: set max cpu frequency
<HZ> on CPU <cpuid>.
xenpm set-scaling-minfreq <cpuid> <HZ>: set min cpu frequency
<HZ> on CPU <cpuid>.
xenpm set-scaling-governor <cpuid> <name>: set scaling governor
on CPU <cpuid>.
xenpm set-scaling-speed <cpuid> <num>: set scaling speed on CPU
<cpuid>.
xenpm set-sampling-rate <cpuid> <num>: set sampling rate on CPU
<cpuid>.
xenpm set-up-threshold <cpuid> <num>: set up threshold on CPU
<cpuid>.
To ease the use of this tool, the shortcut option is supported,
i.e. `xenpm get-cpui' is equal to `xenpm get-cpuidle-states'.
Signed-off-by: Guanqun Lu <guanqun.lu@intel.com>
Extended Bios Data Area (EBDA) can be relocated by the initialization
of PCI option ROM. The IPL boot table is also.
EBDA must be accessed via 0x40E after the initialization.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
When a VMX guest tries to enter real mode, put it in virtual 8086 mode
instead, if that's possible. Handle all errors and corner cases by
falling back to the real-mode emulator.
This is similar to the old VMXASSIST system except it uses Xen's
x86_emulate emulator instead of having a partial emulator in the guest
firmware. It more than doubles the speed of real-mode operation on
VMX.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
When xend is restarted, bootable flags of all disk devices are lost
and then the first disk is marked as bootable by a "compatibility
hack". When a guest domain is created with a mixture of several vbd
and tap devices, the compatibility hack may fail to choose the right
bootable device. Thus preventing the guest to be restarted. This patch
fixes this behavior by remembering bootable flag for each disk device
in xenstore database.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Recently we find a bug on Nahelem machine (totally with two nodes, 6G
memory (3G in each node):
- Start a HVM guest with its all VCPUS pinned to node1, so all its
memory is allocated from node1.
- Reboot the HVM.
- There will be some memory allocated from node0 even there is enough
free memory on node1.
Reason: For security issues, xen will not put all the pages of a dying
hvm to domheap directly, but put them in scrub list and wait for handled
by page_scrub_softirq(). If the dying hvm have a lot of memory,
page_scrub_softirq() will not handle all of them before the start the
hvm. There are some pages belong to node1 still in scrub list, new hvm
can't use pages in it. So this hvm will get different memory
distribution than before. Before changeset 18304, page_scrub_softirq()
can be excuted parallel between all the cpus. Changeset 18305
serialise page_scrub_softirq() and Changeset 18307 serialise
page_scrub_softirq() with a new lock to avoid holding up acquiring
page_scrub_lock in free_domheap_pages(). Those changeset slow the ability
to handle pages in scrub list. So the bug becomes more obvious after.
Patch: This patch modifiers balloon.free to avoid this bug. After
patch, balloon.free will check whether current machine is a numa
system and the new created hvm has all its vcpus in the same node. If
all the conditions above fit, we will wait until all the pages in
scrub list are freed (if waiting time go beyond 20s, we will stop
waiting it.).
This seems to be too restricted at the first glance. We used to only
wait for the free memory size of pinned node is bigger than
required. But as we know HVM memory alloction granularity is 2M. Even
the former condition is satisfied, we still may not find enough
2M-size memory on that node.
Signed-off-by: Ting Zhou <ting.g.zhou@intel.com>
Signed-off-by: Xiaowei Yang <Xiaowei.yang@intel.com>
When xend is restarted, bootloader settings of all running domains are
lost. The attached patches fixes this by saving bootloader and
bootloader_args to xenstore database.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Blktap devices information isn't shown by xentop currently.
xen-unstable c/s 17813 said "blktap devices have statistics
counters (e.g., rd_req, wr_req, oo_req) prepended by tap_".
In fact, it is as follows.
# ls -l /sys/devices/xen-backend/tap-1-769/statistics/
total 0
-r--r--r-- 1 root root 4096 Dec 3 20:37 oo_req
-r--r--r-- 1 root root 4096 Dec 3 20:37 rd_req
-r--r--r-- 1 root root 4096 Dec 3 20:37 rd_sect
-r--r--r-- 1 root root 4096 Dec 3 20:37 wr_req
-r--r--r-- 1 root root 4096 Dec 3 20:37 wr_sect
The statistics counters haven't had "tap_" because it was removed
by linux-2.6.18-xen c/s 34.
This patch reverts xen-unstable c/s 17813, then we can get the
blktap devices information by using xentop.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
I saw an error message when I shut down a domain. The error
message showed that release of device(vbd/51712) failed. But the
device was tap, was not vbd. I think that a cause of the error message is
because _releaseDevices() calls destroyDevice() by wrong device class.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The attached patch relaxes the sanity check on guest configuration
when assigning a acm label to the guest. This patch makes a guest
configuration accept a bootloader parameter. This is common for
paravirtualized guests to boot them by using pygrub.
Signed-off-by: INAKOSHI Hiroya <inakoshi.hiroya@jp.fujitsu.com>
Isaku Yamahata
Keir Fraser