My speculation calling FPSWA within Xen will lead to
1. Set FPSR accordingly to Domain kernel with Xen, and then Save and
restore domain FP registers before/after calling FPSWA in Xen
2. ready to handle FP exceptions caused by FPSWA execution. Note Domain
application can't be trusted so it can likely incure FP exception. Xen
FP exception must also able to distinguish exception source in order to
unwind stack to deliver to domain handler. Will one domain impact Xen
stability?
3. If domains doesn't got passed with FPSWA info, can its FP handler
able to handle exception delivered from Xen?
4. FP opcode fetch must be performed within Xen (likely within FPSWA) to
get from domain application base on IIP. TLB miss may likely happen and
Xen can't handle it.
5. Domain FPSWA usage time is charged to Xen in stead of itself
Xen may not able to handle above issues cleanly :-)
To minic native behavior, can we provide a single physical copy of FPSWA
for whole system without coping for each new domain created? That is,
each domain will be given extra, other than domain memory, physical
block that contains the same FPSWA. The memory is then exported to
domains through EFI descriptor or ELILO (Whatever the native method is)
with guest physical. For P2M, domains will map the FPSWA using exported
guest physical and then Xen will instead map with the same machine
physical block for all the domains.
The assumption here is domains won't write to FPSWA to clobber it
otherwise Xen has to change mapping attribute. Domain destroy may need
to perform special handling on this machine block, but it should be easy
once we have page reference count implemented.
-Fred
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 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
|
Home