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

[Wei Chen <Wei.Chen@xxxxxxx>]

Hi Yuri,

> -----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.


> If we do it, I think it is good idea to implement it in the follow up
> patches.
> 
> -Yuri.
> 
> Wei Chen <Wei.Chen@xxxxxxx> writes:
> 
> > Hi Sharan,
> >
> >> -----Original Message-----
> >> From: Sharan Santhanam <sharan.santhanam@xxxxxxxxx>
> >> Sent: 2018年7月20日 21:28
> >> To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> >> simon.kuenzer@xxxxxxxxx
> >> Cc: Julien Grall <Julien.Grall@xxxxxxx>; Kaly Xin <Kaly.Xin@xxxxxxx>; nd
> >> <nd@xxxxxxx>; Dave P Martin <Dave.Martin@xxxxxxx>
> >> Subject: Re: Re: [Minios-devel] [UNIKRAFT PATCHv4 22/43] plat/kvm: Allow
> >> access to floating-point and Advanced SIMD registers
> >>
> >> Hello,
> >>
> >> On 07/09/2018 12:48 PM, Julien Grall wrote:
> >> > (+ Dave)
> >> >
> >> > On 09/07/18 10:47, Wei Chen wrote:
> >> >> Hi, Julien,
> >> >
> >> > Hi Wei,
> >> >
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: Julien Grall <julien.grall@xxxxxxx>
> >> >>> Sent: 2018年7月8日 6:17
> >> >>> To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> >> >>> simon.kuenzer@xxxxxxxxx
> >> >>> Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> >> >>> Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 22/43] plat/kvm: Allow
> >> access to
> >> >>> floating-point and Advanced SIMD registers
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> On 07/06/2018 10:03 AM, Wei Chen wrote:
> >> >>>> On Arm64, when we want to print out some message, the va_list will
> >> >>>> use the SIMD&FP registers (like q0, q1) to store parameters. So, we
> >> >>>> have to disable the trap of accessing floating-point and Advanced SIMD
> >> >>>> registers to make va_list use SIMD&FP registers properly.
> >> >>>
> >> >>> I don't think this is true. Xen and Linux don't use SIMD&FP registers
> as
> >> >>> this would require to context switch at every entry. Yet we are able to
> >> >>> use va_list without SIMD&FP registers.
> >> >>>
> >> >>
> >> >> This is true, because Linux and Xen doesn't support float print.
> >> >> Unikraft kernel just a part of an application, its print library need
> >> >> To support float. Just like nolibc, when GCC compiling this library,
> >> >> it doesn't care you are running EL1 or EL0, the generated code will
> >> >> access q0, q1. When you're running this code in EL1 without SIMD&FP,
> >> >> system crash.
> >> >
> >>
> >> According to the [2] and [4], Cortex-A53 could be configured and
> >> linux[3] has support for running the soft floating point. But in our
> >> description of Cortex-A53 in "arch/arm/arm64/Config.uk" we restrict it.
> >>
> >> Do we plan to support it in the future?
> >
> > Hmm, Both floating-point and NEON are required in all standard ARMv8
> > implementations. However, as the document[2] mentioned, implementations
> > targeting specialized markets may support No NEON or floating-point.
> >
> > Although I don't really want to support it, but I think I don't have
> > choice. I have to support such specialized users, I prefer to introduce
> > a new target CPU cortex-A53+NOFP to support it in another patch series.
> >
> > About document[3], I can't open the original URL, but I find it in
> > http://lists-archives.com/linux-kernel/28688456-arm64-support-systems-
> without-fp-asimd.html
> >
> > This patch is not for soft floating. It's used to avoid save fp&simd
> > registers in context switch when fpsimd feature is absent.
> > And GCC for AArch64 doesn't support soft-float, if users select the
> > +NOFP option, he must confirm the code don't contain any float type.
> >
> >>
> >> > When will q0, q1 will be accessed? Is it only when floating point will
> >> > be printed?
> >> >
> >>
> >> The document[1], mentions that register qN are used only for floating
> >> and vector operations. In appendix B, where they explain about the
> >
> > Sorry, I haven't found "only" from [1], I just found "can" : )
> >
> >> variadic calling conventions it mentions prologue of the variadic
> >> function creates a separate variadic stack frame and if the Floating
> >> points arguments or vector arguments are not passed as a variadic
> >> argument qN register do not have to be saved and restored.
> >>
> >> For further reference, section 5.4[1] describe how the function
> >> parameters are passed and how the SIMD/floating point register are used.
> >> Appendix B of the document gives a description of variadic functions.
> >>
> >
> > So, without -mgeneral-regs-only flag, gcc va_start, va_list will use
> > qN to pass parameters. As Unikraft is not a kernel, it's part of an
> > application, we will transfer lots of userspace libraries and applications
> > to unikriaft libraries and applications. And most applications on Cloud
> > like DPDK or other network application, the already use SIMD and other
> > vector operations to accelerate transfer speed. Not to mention the image
> > processing applications, FP is mandatory.
> 
> 
> >
> > So I prefer to keep FP&SIMD enabled by default, except +NOFP be selected
> > Explicitly.
> >
> >> > Also, IIUC, the kernel code will be compiled with floating point, right?
> >> > If so, it means the compiler will be able to use floating point for some
> >> > optimization. This will become a problem when receiving a trap as you
> >> > would need to context switch the registers (this assume handler may use
> FP).
> >> >
> >> > Cheers,
> >> >
> >>
> >>
> >>
> >>
> >> [1]
> >>
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf
> >>
> >> [2]
> >> https://developer.arm.com/products/architecture/cpu-architecture/a-
> >> profile/docs/112086438/latest/software-implications-for-v8-a-
> implementations-
> >> with-no-hardware-floating-point
> >>
> >> [3] https://patchwork.kernel.org/patch/9405787/
> >>
> >> [4]
> >>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0773b/chr138314
> >> 3713787.html
> >>
> >> Thanks & Regards
> >> Sharan
> > _______________________________________________
> > Minios-devel mailing list
> > Minios-devel@xxxxxxxxxxxxxxxxxxxx
> > https://lists.xenproject.org/mailman/listinfo/minios-devel
> 
> --
> Yuri Volchkov
> Software Specialist
> 
> NEC Europe Ltd
> Kurfürsten-Anlage 36
> D-69115 Heidelberg
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel