[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]


  • To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Sat, 6 Dec 2008 11:10:22 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 05 Dec 2008 19:10:40 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AclWrqYsAZ45KJ3/RaikQMbrSrBKZgAoUNKQ
  • Thread-topic: [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 <yamahata@xxxxxxxxxxxxx>
>>>> 
>>>> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.