Re: [Minios-devel] [UNIKRAFT PATCHv4 22/43] plat/kvm: Allow access to floating-point and Advanced SIMD registers

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Julien,

(Sorry for my email style, I am replying on my phone)

Ok, if it’s for just now, I agree the turn off the the FP support. Because 
there is not any library using FP currently. I can use -mgeneric-registers-only 
to avoid gcc generating code using qN. And I will add FP options in later patch 
series to enable FP and add FP save&restore to consideration.

Regards,

> 在 2018年7月23日，19:07，Julien Grall <julien.grall@xxxxxxx> 写道：
> 
> Hi,
> 
> On 23/07/18 11:02, Wei Chen wrote:
>>> -----Original Message-----
>>> From: Yuri Volchkov <yuri.volchkov@xxxxxxxxx>
>>> Sent: 2018年7月23日 17:52
>>> To: Wei Chen <Wei.Chen@xxxxxxx>; Sharan Santhanam 
>>> <sharan.santhanam@xxxxxxxxx>;
>>> minios-devel@xxxxxxxxxxxxxxxxxxxx; simon.kuenzer@xxxxxxxxx
>>> Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; Julien Grall <Julien.Grall@xxxxxxx>; nd
>>> <nd@xxxxxxx>; Dave P Martin <Dave.Martin@xxxxxxx>
>>> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 22/43] plat/kvm: Allow access 
>>> to
>>> floating-point and Advanced SIMD registers
>>> 
>>> Hi Wei
>>> 
>>>> As Unikraft is not a kernel.
>>> That is not completely true. That is matter of terminology. We still
>>> separate "kernel" (or "core" if you like) code from the
>>> "application". Even though it is melted together into one address space.
>>> 
>>> Or do you mean it is not a kernel because it runs as a qemu process?
>>> From that perspective yes.. but that is still an OS (virtualized
>>> though). If linux runs in KVM it has a kernel anyways..
>>> 
>> I said it's not a kernel is from the user's view. If you transfer nginx
>> to Unikraft-nginx. I don't think the user will consider Unikraft-nginx
>> is kernel. But from technology view, yes, LIBOS still have the features
>> of a kernel has.
>>> I think it would be best to disable floating point for "core" part. And
>>> if a specific application (e.g. DPDK) needs it, only that application's
>>> code should be build with floating point support.
>>> 
>> No, it's not realistic, the FP feature is a CPU feature. Except we want to
>> do a switch for core and application, We can't enable it for application
>> part only. What we can do is enable FP&SIMD registers access for application
>> but disable FP&SIMD registers for core part through GCC flags. But this means
>> we need two independent code for common functions. For example, you have to
>> compile uk_print_nofp for core with -mgeneric-registers-only, and compile
>> Uk_print for applications.
> 
> I agree with Yuri here. You don't want the "core" to have floating point 
> enabled. If you do enable floating point, you will need to save/restore them 
> on entry/exit of a "syscall" and exception.
> 
> This will add latency on interrupt because of the number of registers to 
> save. I am not even mentioning SVE here... Even Linux, which support only FP 
> in the userspace, has been looking at limiting the save/restore of FP by 
> using a Lazy solution (i.e the FP are enabled on demand).
> 
> FP support is not going to be trivial. Overall I think it would be better if 
> we keep FP support off for now. This could be implemented in a follow-up 
> series.
> 
> Cheers,
> 
> -- 
> Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel