[Xen-ia64-devel] [Patch] fix buildconfigs of domU
Hi, I fix buildconfigs of domU. Signed-off-by: Akio Takebe [EMAIL PROTECTED] Signed-off-by: Yoshiro Fujita [EMAIL PROTECTED] Best Regards, Akio Takebe domU_config.patch Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Weekly benchmark results [ww35]
Hi, all I will inform this week's benchmark result. The tools used now is as follows. - unixbench4.1.0 - bonnie++-1.03 - ltp-full-20060306 - iozone3_191 - lmbench-3.0-a5 TEST ENVIRONMENT Machine : Tiger4 KERN : 2.6.16.13-xen changeset: 11333:586c5fe8cf3e Dom0 OS : RHEL4 U2 (no SMP) DomU OS : RHEL4 U2 (2P) No. of DomU's: 1 Sched: credit issues: - I found a small bug. When I tried the compile with specifying KERNELS=linux-2.6-xenU, the process was stopped at old-config. But, it'll be fixed by the Akio's domU_config.patch. TEST RESULT unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20060306 : 2/817 FAIL (see attachment) iozone3_191 : Pass lmbench-3.0-a5: Pass Thanks and best regards, Fujita and Fujitsu members ltp-domU-20060831.log Description: Binary data ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms
That seems like a good idea to me. Though I think you are missing { }.
Can you test to see if this works?
Oops, You're right. But I think unknown_nmi_error() is not called,
because crash_kexec() is called before that.
Yes, I'll test it. :-)
--- a/xen/arch/x86/traps.c 2006-09-01 11:53:44.0 +0900
+++ b/xen/arch/x86/traps.c 2006-09-01 11:53:56.0 +0900
@@ -1611,8 +1611,10 @@
mem_parity_error(regs);
else if ( reason 0x40 )
io_check_error(regs);
-else if ( !nmi_watchdog )
+else if ( !nmi_watchdog ) {
+ crash_kexec(NULL);
unknown_nmi_error((unsigned char)(reason0xff));
+ }
}
}
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)
Hi, Horms
That seems like a good idea to me. Though I think you are missing { }.
Can you test to see if this works?
Oops, You're right. But I think unknown_nmi_error() is not called,
because crash_kexec() is called before that.
Sorry.
In the only case of CONFIG_KEXEC=y, the above is right.
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] found a small bugRE:[Xen-ia64-devel][PATCH] pal_halt_light emulatefor domU TAKE3
On Thu, 2006-08-31 at 09:44 +0800, Xu, Anthony wrote:
- do_sched_op_compat(SCHEDOP_yield, 0);
+ migrate_timer(v-arch.hlt_timer,
v-arch.hlt_timer.cpu=v-processor;
+ v-processor);
...
I also propose use above assignment state to substitute migrate_timer,
Because at this time hlt_timer is definitely stopped, we can change
hlt_timer.cpu
directly. As we know, migrate_timer may need to get two big spin_locks,
in huge box, I think this may cause performance degradation.
Hi Anthony,
Is the patch below effectively what you are proposing? I'm happy to
remove the migrate_timer() call from schedule_tail if it's unnecessary.
I'm less comfortable with the timer migration shortcut in the
pal_halt_light emulation. While it may work, it violates the timer API,
which could come back to bite us later. Thanks,
Alex
diff -r af50fb41612c xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri Sep 01 08:46:02 2006 -0600
+++ b/xen/arch/ia64/xen/domain.cFri Sep 01 10:33:01 2006 -0600
@@ -122,7 +122,6 @@ void schedule_tail(struct vcpu *prev)
shared_info-vcpu_info[current-vcpu_id].evtchn_upcall_mask;
__ia64_per_cpu_var(current_psr_ic_addr) = (int *)
(current-domain-arch.shared_info_va + XSI_PSR_IC_OFS);
- migrate_timer(current-arch.hlt_timer, current-processor);
}
flush_vtlb_for_context_switch(current);
}
diff -r af50fb41612c xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Fri Sep 01 08:46:02 2006 -0600
+++ b/xen/arch/ia64/xen/hypercall.c Fri Sep 01 10:33:01 2006 -0600
@@ -31,6 +31,12 @@
#include public/callback.h
#include xen/event.h
#include xen/perfc.h
+
+/*
+ * Migrating the hlt_timer between CPUs is rather costly. This avoids
+ * the locking overhead between the CPUs.
+ */
+#undef HLT_TIMER_SAFE_MIGRATION
static long do_physdev_op_compat(XEN_GUEST_HANDLE(physdev_op_t) uop);
static long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
@@ -236,8 +242,13 @@ fw_hypercall (struct pt_regs *regs)
}
else {
perfc_incrc(pal_halt_light);
- migrate_timer(v-arch.hlt_timer,
- v-processor);
+#ifdef HLT_TIMER_SAFE_MIGRATION
+ migrate_timer(v-arch.hlt_timer, v-processor);
+#else
+ if (active_timer(v-arch.hlt_timer))
+ stop_timer(v-arch.hlt_timer);
+ v-arch.hlt_timer.cpu = v-processor;
+#endif
set_timer(v-arch.hlt_timer,
vcpu_get_next_timer_ns(v));
do_sched_op_compat(SCHEDOP_block, 0);
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PV-on-HVM for IPF (take 3)
On Wed, 2006-08-30 at 14:16 +0900, DOI Tsunehisa wrote: You should add least add a comment because it is unusable to see VMX_DOMAIN() within paravirtualization area. OK. I'll append comment to descibe more detail reason. I'll post new expand-memory-op.patch2. I applied this, but I did have to fix mm.h to make it build. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] fix buildconfigs of domU
On Fri, 2006-09-01 at 15:13 +0900, Akio Takebe wrote: Hi, I fix buildconfigs of domU. It didn't seem right to enable the netdev backend on xenU, so I fixed the Kconfig file and updated all the ia64 buildconfigs. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#11414
Xen/IA64 Healthiness Report 11414 got regression. VTI and XenU couldn't be created, after doing several times creating and destroying. It is why nightly testing report shows so many testing cases failed. But they can be pass in manually retest. Three main issues I met: 1. vif could not be connected. The domain creating failed. 2. vbd could not be connected. The domain creating failed. 3. The privileged domain did not balloon. The domain creating failed. 4. device 0 (/796) not connected. XenU creating failed. Testing Environment: Platform: Tiger4 Processor: Itanium 2 Processor Logic Processors number: 8 (2 processors with Due Core) PAL version: 8.15 Service OS: RHEL4u3 IA64 SMP with 2 VCPUs VTI Guest OS: RHEL4u2 RHEL4u3 XenU Guest OS: RHEL4u2 Xen IA64 Unstable tree: 11414:1bab7d65171b Xen Schedule: credit VTI Guest Firmware MD5: b6277539d86d785d8859ea2f99cf6013 Summary Test Report: - Total cases: 15 Passed:5 Failed: 10 Detailed test cases info: - One_VTI_without_vifpass One_VTI pass One_XenU pass Two_VTI_Coexist __fail__ (pass in manually retest) One_VTI_and_One_XenU pass Two_XenU_Coexist __fail__ One_VTI_4096M __fail__ (pass in manually retest) VTI_Network pass XenU_Network __fail__ (pass in manually retest) One_SMP_XenU __fail__ (pass in manually retest) One_SMP_VTI __fail__ (pass in manually retest) UP_VTI_LTP __fail__ (not retest) VTI_Kernel_Build __fail__ (not retest) Four_VTI_Coexist __fail__ (not retest) VTI_Windows __fail__ (pass in manually retest) Notes: - The last stable changeset: - 11333:586c5fe8cf3e Best Regards, Yongkang (Kangkang) 永康 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
