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

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


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.


Julien Grall

Minios-devel mailing list



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