Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 15 Jun 2022 19:14:37 +0100
From:   "Russell King (Oracle)" <linux@armlinux.org.uk>
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     William Zhang <william.zhang@broadcom.com>,
        Linux ARM List <linux-arm-kernel@lists.infradead.org>,
        joel.peshkin@broadcom.com, dan.beygelman@broadcom.com,
        anand.gore@broadcom.com, kursad.oney@broadcom.com,
        samyon.furman@broadcom.com, tomer.yacoby@broadcom.com,
        philippe.reynes@softathome.com,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@broadcom.com>,
        Ray Jui <rjui@broadcom.com>,
        Scott Branden <sbranden@broadcom.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: bcmbca: add VFP and NEON fixup for bcm6846 SoC
Message-ID: <YqohjUuJ7ivSFeMN@shell.armlinux.org.uk>
References: <20220525003509.2812-1-william.zhang@broadcom.com>
 <700e7f0b-a535-545b-1c83-26ce2d4e8be1@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <700e7f0b-a535-545b-1c83-26ce2d4e8be1@gmail.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>
Precedence: bulk

On Wed, Jun 15, 2022 at 10:43:28AM -0700, Florian Fainelli wrote:
> On 5/24/22 17:35, William Zhang wrote:
> > BCM6846 SoC only has VFP and NEON support on core 0. So kernel VPF/NEON
> > support is disabled in this chip. Add this fixup to manually turn on
> > VFP/NEON in case userspace app need to access them on core 0.
> > 
> > Signed-off-by: William Zhang <william.zhang@broadcom.com>
> 
> We have had this conversation internally already, but I do not think this is
> sufficient in order to have a workable solution, you indicated that there is
> all sorts of user-space involvement in your SDK to ensure that only VFP
> tasks are scheduled on core 0, but if we were to seek a proper solution we
> would have to modify the ARM Linux kernel to forcibly migrate VFP tasks onto
> a core that can support executing them, or accept emulating them with the
> implied slow down.
> 
> Russell, what are your thoughts on this?

The patch only enables access to the VFP, which adds the additional
instructions on that core. However, if the kernel has decided that
VFP isn't available, then we won't be advertising VFP via the HWCAPS
and therefore libraries won't be using it.

However, there may be some userspace that "probes" for VFP instruction
presence by trying to execute a VFP instruction, and catching the
SIGILL. The problem here is if we enable it on core 0 and such an app
is used, then it will think VFP is generally available when it isn't.

So, in terms of system stability, I don't think this is something we
want to generally do.

Also, without the VFP kernel support code, VFP registers won't be
saved and restored across context switches (which makes them a nice
path for covert communication) and neither will they be saved and
restored properly for signal handlers - so any use of VFP on that
core would need to be carefully thought through.

It doesn't sound like a particularly good idea for a generic kernel
to me, even one running on the specific hardware. For example, a
debian hardfp userspace may well run on core 0 but not properly.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!