Although I also replied by the bugzilla,
I also send the patch to the list for those who doesn't
watch on the bug report.
I hope this patch fixes it, please try this.

IA64: fix emulation of fp emulation of pv domain.

This patch fixes bug reported as
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392
When pv domain case, the ip can't be accessed by VMM becuase
of tlb cache stuff, the instruction was skipped resulting
in wrong calculation. This patch fixes it.

Signed-off-by: Isaku Yamahata <[EMAIL PROTECTED]>

diff --git a/xen/arch/ia64/xen/faults.c b/xen/arch/ia64/xen/faults.c
--- a/xen/arch/ia64/xen/faults.c
+++ b/xen/arch/ia64/xen/faults.c
@@ -318,6 +318,7 @@ handle_fpu_swa(int fp_fault, struct pt_r
        IA64_BUNDLE bundle;
        unsigned long fault_ip;
        fpswa_ret_t ret;
+       unsigned long rc;
 
        fault_ip = regs->cr_iip;
        /*
@@ -328,16 +329,15 @@ handle_fpu_swa(int fp_fault, struct pt_r
        if (!fp_fault && (ia64_psr(regs)->ri == 0))
                fault_ip -= 16;
 
-       if (VMX_DOMAIN(current)) {
-               if (IA64_RETRY == __vmx_get_domain_bundle(fault_ip, &bundle))
-                       return IA64_RETRY;
-       } else
-               bundle = __get_domain_bundle(fault_ip);
-
-       if (!bundle.i64[0] && !bundle.i64[1]) {
-               printk("%s: floating-point bundle at 0x%lx not mapped\n",
+       if (VMX_DOMAIN(current))
+               rc = __vmx_get_domain_bundle(fault_ip, &bundle);
+       else
+               rc = __get_domain_bundle(fault_ip, &bundle);
+       if (rc == IA64_RETRY) {
+               gdprintk(XENLOG_DEBUG,
+                        "%s: floating-point bundle at 0x%lx not mapped\n",
                       __FUNCTION__, fault_ip);
-               return -1;
+               return IA64_RETRY;
        }
 
        ret = fp_emulate(fp_fault, &bundle, &regs->cr_ipsr, &regs->ar_fpsr,
@@ -689,8 +689,10 @@ ia64_handle_reflection(unsigned long ifa
                if (!status)
                        return;
                // fetch code fail
-               if (IA64_RETRY == status)
+               if (IA64_RETRY == status) {
+                       vcpu_decrement_iip(v);
                        return;
+               }
                printk("ia64_handle_reflection: handling FP trap\n");
                vector = IA64_FP_TRAP_VECTOR;
                break;
diff --git a/xen/arch/ia64/xen/vcpu.c b/xen/arch/ia64/xen/vcpu.c
--- a/xen/arch/ia64/xen/vcpu.c
+++ b/xen/arch/ia64/xen/vcpu.c
@@ -1325,6 +1325,16 @@ static TR_ENTRY *vcpu_tr_lookup(VCPU * v
        return NULL;
 }
 
+unsigned long
+__get_domain_bundle(unsigned long iip, IA64_BUNDLE *bundle)
+{
+       *bundle = __get_domain_bundle_asm(iip);
+       if (!bundle->i64[0] && !bundle->i64[1])
+               return IA64_RETRY;
+
+       return 0;
+}
+
 // return value
 // 0: failure
 // 1: success
@@ -1335,6 +1345,7 @@ vcpu_get_domain_bundle(VCPU * vcpu, REGS
        u64 gpip;               // guest pseudo phyiscal ip
        unsigned long vaddr;
        struct page_info *page;
+       unsigned long rc;
 
  again:
 #if 0
@@ -1387,11 +1398,11 @@ vcpu_get_domain_bundle(VCPU * vcpu, REGS
                if (swap_rr0) {
                        set_virtual_rr0();
                }
-               *bundle = __get_domain_bundle(gip);
+               rc = __get_domain_bundle(gip, bundle);
                if (swap_rr0) {
                        set_metaphysical_rr0();
                }
-               if (bundle->i64[0] == 0 && bundle->i64[1] == 0) {
+               if (rc == IA64_RETRY) {
                        dprintk(XENLOG_INFO, "%s gip 0x%lx\n", __func__, gip);
                        return 0;
                }
diff --git a/xen/arch/ia64/xen/xenasm.S b/xen/arch/ia64/xen/xenasm.S
--- a/xen/arch/ia64/xen/xenasm.S
+++ b/xen/arch/ia64/xen/xenasm.S
@@ -389,7 +389,7 @@ END(ia64_prepare_handle_reflection)
 END(ia64_prepare_handle_reflection)
 #endif
 
-GLOBAL_ENTRY(__get_domain_bundle)
+GLOBAL_ENTRY(__get_domain_bundle_asm)
        EX(.failure_in_get_bundle,ld8 r8=[r32],8)
        ;;
        EX(.failure_in_get_bundle,ld8 r9=[r32])
@@ -403,7 +403,7 @@ GLOBAL_ENTRY(__get_domain_bundle)
        ;;
        br.ret.sptk.many rp
        ;;
-END(__get_domain_bundle)
+END(__get_domain_bundle_asm)
 
 /* derived from linux/arch/ia64/hp/sim/boot/boot_head.S */
 GLOBAL_ENTRY(pal_emulator_static)
diff --git a/xen/include/asm-ia64/bundle.h b/xen/include/asm-ia64/bundle.h
--- a/xen/include/asm-ia64/bundle.h
+++ b/xen/include/asm-ia64/bundle.h
@@ -225,7 +225,8 @@ typedef union U_INST64 {
 
 #ifdef __XEN__
 extern unsigned long __vmx_get_domain_bundle(unsigned long iip, IA64_BUNDLE 
*pbundle);
-extern IA64_BUNDLE __get_domain_bundle(unsigned long iip);
+extern IA64_BUNDLE __get_domain_bundle_asm(unsigned long iip);
+extern unsigned long __get_domain_bundle(unsigned long iip, IA64_BUNDLE 
*bundle);
 #endif
 
 #define MASK_41 ((unsigned long)0x1ffffffffff)


On Wed, Dec 03, 2008 at 12:40:59PM -0700, Alex Williamson wrote:
> 
> This looks pretty nasty and it still occurs on latest upstream.  The
> test program in the bugzilla usually shows the problem within a couple
> runs.  Thanks,
> 
> Alex
> 
> 
> -------- Forwarded Message --------
> > From: [EMAIL PROTECTED]
> > Reply-to: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: [Xen-bugs] [Bug 1392] New: Problems with denormalized
> > floating point numbers on XEN-virtualized Linux/IA64
> > Date: Wed, 3 Dec 2008 08:34:59 -0800
> > 
> > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392
> > 
> >            Summary: Problems with denormalized floating point numbers on
> >                     XEN-virtualized Linux/IA64
> >            Product: Xen
> >            Version: 3.0.3
> >           Platform: IA64
> >         OS/Version: Linux
> >             Status: NEW
> >           Severity: normal
> >           Priority: P2
> >          Component: Unspecified
> >         AssignedTo: [EMAIL PROTECTED]
> >         ReportedBy: [EMAIL PROTECTED]
> >                 CC: [EMAIL PROTECTED]
> > 
> > 
> > Hi,
> > 
> > while we were testing our Java VM on a XEN-virtualized Linux/IA64 we
> > encountered some non-deterministic, but reproducible floating point 
> > failures.
> > After some debugging we could exclude the Java VM as the root cause of the
> > problem and came up with the following small C++ test case, which usually 
> > fails
> > on a virtualized Linux box. We couldn't however reproduce the failure on any
> > other, non-virtualized IA64 Linux.
> > 
> > Attached you can find the test program "fnorms.cpp". Please compile with 
> > 'gcc
> > -g fnorms.cpp'. The program will silently finish if no error occurs, 
> > otherwise
> > it will print one or more lines like: "ERROR: 1.401298e-45 != 1.000000e+00".
> > 
> > During our debugging sessions, we observed that the reason for the failure 
> > is
> > that certain IA64 floating point instructions like 'fnorm.s', 'fmpy.s' or
> > 'fcmp' may fail if they are applied to denormalized floating point values.
> > 
> > If the multiplication ('fmpy.s') fails, the error line shows different 
> > numbers
> > (e.g. "ERROR: 1.401298e-45 != 1.000000e+00"). But thre's also a case where 
> > the
> > compare fails (i.e. the 'fcmp' which was generated for "if (result !=
> > min_float)"). If this happens, the test program "erroneously" reports that 
> > the
> > result of the multiplication and the initial value of "min_float" differ
> > ("ERROR: 1.401298e-45 != 1.401298e-45"), although the two numbers are really
> > equal.
> > 
> > Because we have only observed these failures on a Xen-virtualized IA64-Linux
> > version (in both, dom0 and dom1) our assumption is that there may be a 
> > problem
> > in the implementation of the Floating Point Software Assistance (FPSWA) in 
> > Xen,
> > because all of the above mentioned instructions generate a "floating-point
> > assist fault" if they are applied to denormalized values (as can be seen in
> > "/var/log/messages").  This is only a vague guess however...
> > 
> > Has anybody seen these problems before or are there any ideas why this 
> > happens?
> > 
> > With best regards,
> > Volker
> > 
> > PS: we have tested on:
> > 
> > Xen: 3.0.3-64
> > 
> > dom0: RHEL 5.2
> > ---------------
> > [EMAIL PROTECTED] ~]# uname -a
> > Linux xxxxxx.wdf.sap.corp 2.6.18-92.el5xen #1 SMP Tue Apr 29 13:36:07 EDT 
> > 2008
> > ia64 ia64 ia64 GNU/Linux
> > [EMAIL PROTECTED] ~]# lsb_release -a
> > LSB Version:   
> > :core-3.1-ia64:core-3.1-noarch:graphics-3.1-ia64:graphics-3.1-noarch
> > Distributor ID: RedHatEnterpriseServer
> > Description:    Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> > Release:        5.2
> > Codename:       Tikanga
> > [EMAIL PROTECTED] ~]# rpm -q xen
> > xen-3.0.3-64.el5_2.1
> > [EMAIL PROTECTED] ~]# xm info
> > host                   : xxxxxx.wdf.sap.corp
> > release                : 2.6.18-92.el5xen
> > version                : #1 SMP Tue Apr 29 13:36:07 EDT 2008
> > machine                : ia64
> > nr_cpus                : 4
> > nr_nodes               : 1
> > sockets_per_node       : 2
> > cores_per_socket       : 2
> > threads_per_core       : 1
> > cpu_mhz                : 1594
> > hw_caps                :
> > 00000000:00000000:00000000:00000000:00000000:00000000:00000000:00000000:
> > total_memory           : 32722
> > free_memory            : 17277
> > node_to_cpu            : node0:no cpus
> > xen_major              : 3
> > xen_minor              : 1
> > xen_extra              : .2-92.el5
> > xen_caps               : xen-3.0-ia64 xen-3.0-ia64be hvm-3.0-ia64 
> > xen_pagesize           : 16384
> > platform_params        : virt_start=0xe800000000000000
> > xen_changeset          : unavailable
> > cc_compiler            : gcc version 4.1.2 20071124 (Red Hat 4.1.2-41)
> > cc_compile_by          : brewbuilder
> > cc_compile_domain      : redhat.com
> > cc_compile_date        : Tue Apr 29 13:14:31 EDT 2008
> > xend_config_format     : 2
> > 
> > dom1: RHEL 5.2 (2.6.18-53.1.14.el5xen #1 SMP Tue Feb 19 07:35:46 EST 2008 
> > ia64)
> > ---------------
> > 
> > # cat /proc/cpuinfo 
> > processor  : 0
> > vendor     : Xen/ia64
> > arch       : IA-64
> > family     : 32
> > model      : 0
> > revision   : 7
> > archrev    : 0
> > features   : branchlong, 16-byte atomic ops
> > cpu number : 0
> > cpu regs   : 4
> > cpu MHz    : 1594.000895
> > itc MHz    : 399.222286
> > BogoMIPS   : 3006.46
> > siblings   : 1
> > 
> > processor  : 1
> > vendor     : Xen/ia64
> > arch       : IA-64
> > family     : 32
> > model      : 0
> > revision   : 7
> > archrev    : 0
> > features   : branchlong, 16-byte atomic ops
> > cpu number : 0
> > cpu regs   : 4
> > cpu MHz    : 1594.000895
> > itc MHz    : 399.222286
> > BogoMIPS   : 3178.49
> > siblings   : 1
> > 
> > CPUID0: 0x756E6547
> > CPUID1: 0x6C65746E
> > CPUID2: 0x0
> > CPUID3: 0x20000704
> > CPUID4: 0x5
> > 
> > 

-- 
yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Reply via email to