search for: do_dom0_op

The latest change to ACM makes it fail to compile. This patch fixes the problem. Signed-off-by: Nguyen Anh Quynh <aquynh@gmail.com> $ diffstat acm.patch acm/acm_core.c | 61 --------------------- include/acm/acm_hooks.h | 135 ++++++++++++++++++++++++++++++++++-------------- 2 files changed, 96 insertions(+), 100 deletions(-) _______________________________________________

Last year we had a discussion[1] about how the hypercall ABI unfortunately contains fields that change width between 32- and 64-bit builds. This is a huge problem as we come up on the python management stack for ppc64, since the distributions ship 32-bit python. A 32-bit python/libxc cannot currently manage a 64-bit hypervisor. I had a patch but was unable to test it, and some other things were

...alls are called in C. However, they are not declared in any .h file. I think it is cleaner to declare them in an header file rather than locally. The question is in which header file. Thank you for any suggestion. The do_* functions are at least: extern long do_ni_hypercall(void); extern long do_dom0_op(dom0_op_t *u_dom0_op); extern long do_memory_op(int cmd, void *arg); extern long do_multicall(multicall_entry_t *call_list, unsigned int nr_calls); extern long do_event_channel_op(evtchn_op_t *uop); extern long do_xen_version(int cmd, void *arg); extern long do_console_io(int cmd, int count, char *...

...unisys_acpi_oem_table: 1296 0xffff83000011182e do_xen_version: 1280 0xffff83000015bc3e x86_emulate_memop: 1264 0xffff8300001adbaa vmx_world_save: 1040 0xffff8300001aeac5 vmx_world_save: 1040 0xffff830000106800 do_dom0_op: 968 0xffff8300001080cf do_dom0_op: 968 0xffff830000137c64 construct_dom0: 968 0xffff83000013a81e construct_dom0: 968 0xffff8300001b1dbc vmx_vmexit_handler: 632 0xffff8300001b2f58 vmx_vmexit...

Keir, The patch below is necessary to get ia64 building on current xen-unstable.hg. Thanks, Alex Signed-off-by: Alex Williamson <alex.williamson@hp.com> --- diff -r 3983e4f1b054 xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mk Sun Mar 12 10:03:33 2006 +0100 +++ b/xen/arch/ia64/Rules.mk Mon Mar 13 09:36:01 2006 -0700 @@ -12,7 +12,7 @@ CPPFLAGS += -I$(BASEDIR)/include -I$(BA

...t;] free_shadow_pages+0x3b9/0x43f (XEN) [<ff14f52e>] __shadow_mode_disable+0x2a/0x11c (XEN) [<ff12ab9a>] shadow_mode_disable+0x83/0x134 (XEN) [<ff12aac3>] domain_relinquish_resources+0x188/0x1dc (XEN) [<ff105317>] domain_kill+0x6b/0xa7 (XEN) [<ff1039df>] do_dom0_op+0x8d9/0x19d4 (XEN) [<ff180ac7>] hypercall+0x97/0xb7 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) CPU0 FATAL TRAP: vector = 6 (invalid opcode) (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... ___________________...

...(Each undeclared identifier is reported only once xc_private.h:68: for each function it appears in.) xc_private.h:69: `IOCTL_PRIVCMD_HYPERCALL'' undeclared (first use in this functio n) xc_private.h:70: `hypercall'' undeclared (first use in this function) xc_private.h: In function `do_dom0_op'': xc_private.h:76: `privcmd_hypercall_t'' undeclared (first use in this function) xc_private.h:76: syntax error before "hypercall" xc_private.h:80: `hypercall'' undeclared (first use in this function) In file included from xc_atropos.c:9: xc_private.h: In function...

I am getting the following error when I try to bring up Mini-OS on x86_64 Xen (unstable: 9994). It is dying in xc_linux_build() causing xend to fault and restart. Any clue why this happening? Has something changed in the builder that Mini-OS needs to be aware of? PS: I tried reverting changeset 9993 (Allow linking of mini-os with application-specific object code), but still got the same error

Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU''s memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).

I''ve put together two patches. The first introduces a new dom0_op, set_max_vcpus, which with an associated variable and a check in the VCPUOP handler fixes [1]bug 288. Also included is a new VCPUOP, VCPUOP_create, which handles all of the vcpu creation tasks and leaves initialization and unpausing to VCPUOP_initialize. The separation allows for build-time allocation of vcpus which