[Xen-ia64-devel] [IA64] Weekly benchmark results [ww48]
Hi, I report a benchmark result of this week on IPF using ia64/xen-unstable and ia64/linux-2.6.18-xen. On domU syslog05 failed, but passed when tested again. TEST ENVIRONMENT Machine : Tiger4 Kernel : 2.6.18.8-xen Changeset: 18832:54e5d15af567 (ia64/xen-unstable) 743:6743af9fffc6 (ia64/linux-2.6.18-xen) 131:9210bd27a551 (efi-vfirmware) b4d410a(qemu-xen-unstable) Dom0 OS : RHEL4 U2 (2P) DomU OS : RHEL4 U2 (8P, using tap:aio) DomVTi OS: RHEL4 U2 (8P, with PV-on-HVM drivers) CONFIG_QEMU : ioemu-remote TEST RESULTS DomU: unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20070930 : 1/835 FAIL iozone3_191 : Pass lmbench-3.0-a5: Pass DomVTi: unixbench4.1.0: Pass bonnie++-1.03 : Pass ltp-full-20070930 : Pass iozone3_191 : Pass lmbench-3.0-a5: Pass Best regards, KUWAMURA Shin'ya and Fujitsu members Test Start Time: Thu Dec 4 10:37:47 2008 - Testcase Result Exit Value -- -- abort01PASS 0 accept01 PASS 0 access01 PASS 0 access02 PASS 0 access03 PASS 0 access04 PASS 0 access05 PASS 0 acct01 PASS 0 acct02 PASS 0 adjtimex01 PASS 0 adjtimex02 PASS 0 alarm01PASS 0 alarm02PASS 0 alarm03PASS 0 alarm05PASS 0 alarm06PASS 0 alarm07PASS 0 asyncio02 PASS 0 bind01 PASS 0 bind02 PASS 0 brk01 PASS 0 capget01 PASS 0 capget02 PASS 0 capset01 PASS 0 capset02 PASS 0 chdir01PASS 0 chdir01A PASS 0 chdir02PASS 0 chdir03PASS 0 chdir04PASS 0 chmod01PASS 0 chmod01A PASS 0 chmod02PASS 0 chmod03PASS 0 chmod04PASS 0 chmod05PASS 0 chmod06PASS 0 chmod07PASS 0 chown01PASS 0 chown02PASS 0 chown03PASS 0 chown04PASS 0 chown05PASS 0 chroot01 PASS 0 chroot02 PASS 0 chroot03 PASS 0 chroot04 PASS 0 clone01PASS 0 clone02PASS 0 clone03PASS 0 clone04PASS 0 clone05PASS 0 clone06PASS 0 clone07PASS 0 close01PASS 0 close02PASS 0 close08PASS 0 confstr01 PASS 0 connect01 PASS 0 creat01PASS 0 creat03PASS 0 creat04PASS 0 creat05PASS 0 creat06PASS 0 creat07PASS 0 creat08PASS 0 creat09PASS 0 dup01 PASS 0 dup02 PASS 0 dup03 PASS 0 dup04 PASS 0 dup05 PASS 0 dup06 PASS 0 dup07 PASS 0 dup201 PASS 0 dup202 PASS 0 dup203 PASS 0 dup204 PASS 0 dup205
[Xen-ia64-devel] Please pull ia64 trees
Hi Keir, Please pull the ia64 trees: http://xenbits.xensource.com/ext/ia64/xen-unstable.hg http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg This includes ia64 specific PHYSDEVOP_pirq_eoi_gmfn stuff. Without those, dom0 doesn't boot. Thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]
Isaku Yamahata wrote:
On Fri, Dec 05, 2008 at 04:02:51PM +0900, Isaku Yamahata wrote:
On Fri, Dec 05, 2008 at 02:36:25PM +0800, Zhang, Xiantao wrote:
Isaku Yamahata wrote:
For those who want to test it, here is the slightly update patch.
NOTE: this version doesn't solve the potential infinite loop
which Alex is suspecting about.
IA64: fix emulation of fp emulation
This patch fixes bug reported as
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392
When pv domain case, FPSWA hypercall isn't implemented properly.
So avoid the injecting floating point fault/trap at this moment.
However this may cause infinite loop depending on dtlb cache.
The right fix is to implement the hypercall properly however
it wouldn't be very straight forward because the argument
of fpswa is large and includes pointers.
When hvm domain case, floating point trap case iip was incremented
improperly. removed the increment
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/xen/arch/ia64/vmx/vmx_fault.c
b/xen/arch/ia64/vmx/vmx_fault.c --- a/xen/arch/ia64/vmx/vmx_fault.c
+++ b/xen/arch/ia64/vmx/vmx_fault.c
@@ -130,10 +130,8 @@ void vmx_reflect_interruption(u64 ifa, u
status = handle_fpu_swa(0, regs, isr);
if (!status)
return;
-else if (IA64_RETRY == status) {
-vcpu_decrement_iip(vcpu);
+else if (IA64_RETRY == status)
return;
-}
break;
case 29: // IA64_DEBUG_VECTOR
Hi, Isaku
Why do you think the decrement is useless ? For trap case, the
iip should point to the next instruction instead of the one which
results in the trap. So once need retry, the iip should be back to
the privious one ?
Ouch, you are correct.
When I compared the handler with Linux one, I was confused.
Hmm, more thoughts.
Trap means that the instruction was already executed, so backing iip
means the instruction will be executed twice.
The result would be wrong. For example, how about if the destination
register is one of the source register.
(Or is it safe to execute the instruction twice given that
FP trap was triggered? I'm not sure about such a corner case. need
to dig into the specs...)
Oh, that maybe a potential issue we didn't sense it before.
If we fail to get a bundle in a guest when FP trap,
we can't reexecute the instruction. We have to inject floating
point trap into guest.
For HVM, injecting it to guest should be the right way to go.
Arrg, so FPSWA hypercall has to be implemented correctly?
What about HVM domain case?
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
