RE: [Xen-ia64-devel] Floating-point software assist (FPSWA) on Xen-ia64

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Mimic'ing the same way for native Linux is a lot
more complicated because fpswa.efi is in machine
memory.  This is OK for current domain0 (V==P) but
for P2M or VP, it would need to be copied into
the guest physical space for each domU or multiply
mapped somehow. I guess this is what your Guest
Firmware does, but for paravirtualized guests it
would have to be copied/mapped by Xen or a bunch
of new P2M code would need to be added to Xenlinux.

Your solution might still be the best longterm answer
to maximize identical behavior to Linux, but
paravirtualizing has some virtues... presenting
a more fully functional virtual FPU (by completely
hiding the FPSWA) could be beneficial for some users.

So not a clear win either way...

Dan

> -----Original Message-----
> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx] 
> Sent: Thursday, January 26, 2006 5:58 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] Floating-point software assist 
> (FPSWA) on Xen-ia64
> 
> How about minic how native Linux does for FPSWA instead for 
> Xen to handle extra FP stuff.
> 
> Somehow the FPSWA information should be passed to Domains for 
> them to map into their own address space.  It seems Domain0 
> doesn't get FPSWA info, so will happen on DomainU.
> 
> Somehow how FPSWA info got passed to native kernel should be 
> understood, then Xen can also pass the info accordingly for 
> Domains to map it.
> 
> -Fred
> 
> Magenheimer, Dan (HP Labs Fort Collins) wrote:
> > OK, so no conflict with VT-I.
> > 
> > I'm thinking the best non-VTI implementation for now will
> > be to call fpswa from inside Xen.  This will appear
> > to guests as if all the complex floating point ops
> > that were previously handled by FPSWA are now handled
> > "in hardware".  The disadvantage of this approach is
> > that uses of fpswa will not be able to be tracked and
> > reported (as they are today in Linux/ia64) because the
> > guest will never see them.
> > 
> > Any comments?
> > 
> > Dan
> > 
> >> -----Original Message-----
> >> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx]
> >> Sent: Thursday, January 26, 2006 2:37 PM
> >> To: Magenheimer, Dan (HP Labs Fort Collins);
> >> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: RE: [Xen-ia64-devel] Floating-point software 
> assist (FPSWA)
> >> on Xen-ia64 
> >> 
> >> For native, the platform firmware comes with build-in FPSWA.  If
> >> there is a new FPSWA.efi presented in the disk, the firmware will
> >> drop its default FPSWA. 
> >> 
> >> For DomainVTI to run, there is a Guest Firmware (GFW), with default
> >> FPSWA build-in, presented to domain.
> >> 
> >> -Fred
> >> 
> >> There is Guest Firmware (GFW) used for DomainVTI.
> >> Magenheimer, Dan (HP
> >> Labs Fort Collins) wrote:
> >>> Yongkang has discovered that some LTP tests fail
> >>> because Xen/ia64 (non-VTI) does not support FPSWA.
> >>> Non-support of FPSWA is a known problem that has
> >>> been on the to-do list for some time:
> >>> 
> >>> 
> >> http://lists.xensource.com/archives/html/xen-devel/2004-12/msg
> >> 00382.html
> >>> 
> >>> but this is the first time that it has been seen
> >>> in real (test) usage.
> >>> 
> >>> Yongkang says that the test works with VTI.  How does
> >>> VTI handle FPSWA?  Is direct access to fpswa.efi provided
> >>> to every domain or is fpswa.efi "owned" by the hypervisor
> >>> and floating-point assist traps handled by Xen invisibly 
> to domains?
> >>> 
> >>> A couple of related questions:  Is fpswa.efi re-entrant?
> >>> Does fpswa.efi ever disable interrupts?
> >>> 
> >>> I don't think this will be hard to fix, but it would
> >>> be best if the implementation is consistent between
> >>> VTI and non-VTI.
> >>> 
> >>> Thanks,
> >>> Dan
> >>> 
> >>> _______________________________________________
> >>> Xen-ia64-devel mailing list
> >>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> >>> http://lists.xensource.com/xen-ia64-devel
> 
> 

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