From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@ml01.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E04DD211B5A34 for ; Tue, 29 Jan 2019 05:23:41 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 07518C063D04; Tue, 29 Jan 2019 13:23:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-45.rdu2.redhat.com [10.10.121.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC4E6600CC; Tue, 29 Jan 2019 13:23:38 +0000 (UTC) To: xinliang , Tan Xiaojun Cc: Mark Rutland , Ard Biesheuvel , Marc Zyngier , "edk2-devel@lists.01.org" , Christoffer Dall References: <1449471969-16949-1-git-send-email-ard.biesheuvel@linaro.org> <2dd4294c-76f0-f433-cbd2-bf0b37114aee@redhat.com> <12fa0861-e25d-eba7-48ea-2bd7d47d58fb@redhat.com> <20190128104634.xnaivxxbvad7jffo@blommer> <70ec9046-cb9d-74e8-e64c-4d5fbeba4bfb@redhat.com> <5C4EFF06.2050600@huawei.com> <20190128134618.GB20888@lakrids.cambridge.arm.com> <5C4FF71B.1060606@huawei.com> <5C5036DF.9060905@hisilicon.com> From: Laszlo Ersek Message-ID: <107c4c86-9679-377a-136b-61370923298d@redhat.com> Date: Tue, 29 Jan 2019 14:23:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5C5036DF.9060905@hisilicon.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 29 Jan 2019 13:23:41 +0000 (UTC) Subject: Re: [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to PoU X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 13:23:42 -0000 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/29/19 12:19, xinliang wrote: > > > On 2019/1/29 14:47, Tan Xiaojun wrote: >> +cc Xinliang >> >> Sorry, I didn't react to what you discussed at the beginning, because >> this >> problem is mainly handled by Xinliang. >> >> The host we used for testing is Huawei D06 (AArch64), and its CPU chip is >> 1620 (self-developed chip that follows the arm v8.2 specification). >> Its vmid >> is 16 bit. >> >> Thanks. >> Xiaojun. >> >> On 2019/1/28 21:46, Mark Rutland wrote: >>> On Mon, Jan 28, 2019 at 09:09:26PM +0800, Tan Xiaojun wrote: >>>> On 2019/1/28 19:54, Laszlo Ersek wrote: >>>>> On 01/28/19 11:46, Mark Rutland wrote: >>>>>> On Wed, Jan 23, 2019 at 10:54:56AM +0100, Laszlo Ersek wrote: >>>>>>> And even on the original (unspecified) hardware, the same binary >>>>>>> works >>>>>>> frequently. My understanding is that there are five VMs executing >>>>>>> reboot >>>>>>> loops in parallel, on the same host, and 4 out of 5 may hit the >>>>>>> issue in >>>>>>> a reasonable time period (300 reboots or so). >>>>>> Interesting. >>>>>> >>>>>> Do you happen to know how many VMID bits the host has? If it has >>>>>> an 8-bit VMID, >>>>>> this could be indicative of some problem upon overflow. >>>>> I'll let Tan Xiaojun (CC'd) answer this questions. >>>>> >>>>>> Can you point us at the host kernel? >>>>> In the report, Tan Xiaojun wrote "4.18.0-48.el8.aarch64"; I guess that >>>>> information is mostly useless in an upstream discussion. >>>>> Unfortunately, >>>>> I couldn't reproduce the symptom at all (I know nothing about the >>>>> hardware in question), so I can't myself retest with an upstream host >>>>> kernel. >>>> I don't understand, what do you want me to do? What is the specific >>>> problem? >>> Could you let us know which CPU/system you've seen this issue with? >>> >>> ... and what the value of ID_AA64MMFR1_EL1.VMIDBits is? > > Hi, our hardware is D06 board which compatible with armv8.1. So it > should be 16-bit VMID. > > BTW, we now only reproduce this issue on guest without shim, such as > suse SLE15-SP1 guest which is easy to reproduce. This founding not sure > could help for this issue. Unfortunately, it doesn't help without access to the host -- I used the exact same guest installer ISO from the original report, and failed to reproduce the symptom. ... Since we've been discussing this for a while in public too, can someone from Huawei please authorize Red Hat to open up to the public? If you agree, please comment so on the BZ itself. Thanks! Laszlo