search for: dom0_op_t

...lled 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 *buffer); e...

...node * - physinfo.nr_nodes); + return physinfo.nr_cpus; } diff -r 51045f276c90 xen/arch/ia64/xen/dom0_ops.c --- a/xen/arch/ia64/xen/dom0_ops.c Mon Jul 31 10:48:48 2006 -0500 +++ b/xen/arch/ia64/xen/dom0_ops.c Mon Jul 31 10:49:10 2006 -0500 @@ -203,6 +203,7 @@ long arch_do_dom0_op(dom0_op_t *op, XEN_ cpus_weight(cpu_core_map[0]) / pi->threads_per_core; pi->sockets_per_node = num_online_cpus() / cpus_weight(cpu_core_map[0]); + pi->nr_cpus = (u32)num_online_cpus(); pi->nr_nodes = 1; pi->total_pa...

...his. > >I guess there''s an argument for renaming the arch-specific dom0 ops to >put X86 or IA64 in the name, but I don''t think there''s any real >confusion. Perhaps we should split out arch definitions from dom0_ops.h? That''s one way. Then union "dom0_op_t" may have a new field named arch_dom0_op_t, which is defined in separate arch_dom0_ops.h. Furthermore, include/public will have sub-directory then. If people all agree on this direction, other files with similar requirement, like arch_ia64.h, arch_x86_32.h, ..., may also be split like this way...

...om> diff -r 09bc238664cb -r dc12f0942649 tools/xenmon/xenbaked.c --- a/tools/xenmon/xenbaked.c Mon Aug 14 15:40:36 2006 +0100 +++ b/tools/xenmon/xenbaked.c Mon Aug 14 23:57:43 2006 +0100 @@ -444,14 +444,11 @@ struct t_rec **init_rec_ptrs(struct t_bu */ unsigned int get_num_cpus(void) { - dom0_op_t op; + xc_physinfo_t physinfo; int xc_handle = xc_interface_open(); int ret; - op.cmd = DOM0_PHYSINFO; - op.interface_version = DOM0_INTERFACE_VERSION; - - ret = xc_dom0_op(xc_handle, &op); + ret = xc_physinfo(xc_handle, &physinfo); if ( ret != 0 ) { @@...

...const char *cmdline, unsigned int control_evtchn, unsigned long flags, - unsigned int vcpus) + unsigned int vcpus, + unsigned int store_evtchn, + unsigned long *store_mfn) { dom0_op_t launch_op, op; int initrd_fd = -1; @@ -381,7 +392,8 @@ &vstartinfo_start, &vkern_entry, ctxt, cmdline, op.u.getdomaininfo.shared_info_frame, - control_evtchn, flags, vcpus) < 0 ) +...

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

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

...unsigned int vcpus, > unsigned int store_evtchn, >- unsigned long *store_mfn) >+ unsigned long *store_mfn, >+ unsigned int console_evtchn, >+ unsigned long *console_mfn) > { > dom0_op_t launch_op, op; > int initrd_fd = -1; >@@ -707,7 +720,8 @@ > &vstack_start, ctxt, cmdline, > op.u.getdomaininfo.shared_info_frame, > control_evtchn, flags, vcpus, >- store_evtchn, store_mfn)...