Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Jerome Forissier <jerome@forissier.org>
Subject: optee: regression with kernel v5.14 (virtualization)
To:     Jens Wiklander <jens.wiklander@linaro.org>,
        Sumit Garg <sumit.garg@linaro.org>,
        "op-tee@lists.trustedfirmware.org" <op-tee@lists.trustedfirmware.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Tyler Hicks <tyhicks@linux.microsoft.com>,
        Volodymyr Babchuk <vlad.babchuk@gmail.com>
Message-ID: <a0e1c245-8209-a173-18c4-d21433bf46bf@forissier.org>
Date:   Tue, 28 Sep 2021 15:08:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

I met an issue when testing OP-TEE with the latest released kernel
(v5.14). The kernel won't boot when virtualization is enabled. More
precisely, the boot hangs as the optee driver is probed. The last line
on the console is:

[xxx] optee: probing for conduit method.

The issue can easily be reproduced in the QEMU OP-TEE environment as
documented in [1]:

$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
$ repo sync -j10
$ cd linux
$ git fetch github --unshallow
$ git checkout v5.14
$ cd ../build
$ make -j2 toolchains
$ make -j10 XEN_BOOT=y run

[Note, if you switch between XEN_BOOT=y and the default build, you need
to "make arm-tf-clean"]

git bisect points at commit b5c10dd04b74 ("optee: Clear stale cache
entries during initialization") and reverting this commit on top of
v5.14 does resolve the issue.

Any idea what's wrong?

[1]
https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8

Thanks,
-- 
Jerome