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

[Wei Chen <Wei.Chen@xxxxxxx>]

> -----Original Message-----
> From: Minios-devel <minios-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
> Wei Chen
> Sent: 2018年7月23日 18:02
> To: Yuri Volchkov <yuri.volchkov@xxxxxxxxx>; 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 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.
> 
> 

Another solution is to use a FP_SIMD_ENABLE option explicitly for users to
Select. This option is a global switch, DPDK users know they will use FP&SIMD
Registers then they can switch it on. Otherwise, we will keep this switch off?

How do you think of it?

> > 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
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel