From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [PATCH] igb_uio: fail and log if kernel lock down is
	enabled
Date: Wed, 16 May 2018 10:53:41 +0100
Message-ID: <2b391ab8-270a-c038-5cbe-58886fb43a9c@intel.com>
References: <20180515165612.61243-1-ferruh.yigit@intel.com>
 <20180515115232.5648f749@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: dev@dpdk.org, Christian Ehrhardt <christian.ehrhardt@canonical.com>,
 Luca Boccassi <bluca@debian.org>,
 Maxime Coquelin <maxime.coquelin@redhat.com>,
 Neil Horman <nhorman@tuxdriver.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 7055C1B3D9
 for <dev@dpdk.org>; Wed, 16 May 2018 11:53:44 +0200 (CEST)
In-Reply-To: <20180515115232.5648f749@xeon-e3>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 5/15/2018 7:52 PM, Stephen Hemminger wrote:
> On Tue, 15 May 2018 17:56:12 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> 
>> When EFI secure boot is enabled, it is possible to lock down kernel and
>> prevent accessing device BARs and this makes igb_uio unusable.
> 
> This distro specific (and not upstream) stuff in igb_uio is getting
> to be a significantly ugly. Can this be detected by seeing if one
> of the calls (such setup bars) failing?

Agreed that it is ugly.
igb_uio already will fail in these systems, we can detect failure but the target
is detect reason of failure and inform user about root cause.
I can't think of any other way than using distro specific stuff for this case.

> 
> The best long term solution would be getting all kernel modules upstream;
> but it looks like that will never happen due to UIO maintainer resistance.
>