From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755123AbdC2Jhq (ORCPT ); Wed, 29 Mar 2017 05:37:46 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:4904 "EHLO dggrg03-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754724AbdC2Jhn (ORCPT ); Wed, 29 Mar 2017 05:37:43 -0400 Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS References: <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> CC: Achin Gupta , James Morse , Christoffer Dall , , Marc Zyngier , , , , , , , , , , , , , , , , , To: , , , , From: gengdongjiu Message-ID: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> Date: Wed, 29 Mar 2017 17:36:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <58DA67BA.8070404@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.142.68.147] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58DB803A.00D7,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ed8ca8d6f08004e437408708d9a70339 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laszlo/Biesheuvel/Qemu developer, Now I encounter a issue and want to consult with you in ARM64 platform， as described below: when guest OS happen synchronous or asynchronous abort, kvm needs to send the error address to Qemu or UEFI through sigbus to dynamically generate APEI table. from my investigation, there are two ways: (1) Qemu get the error address, and generate the APEI table, then notify UEFI to know this generation, then inject abort error to guest OS, guest OS read the APEI table. (2) Qemu get the error address, and let UEFI to generate the APEI table, then inject abort error to guest OS, guest OS read the APEI table. Do you think which modules generates the APEI table is better? UEFI or Qemu? On 2017/3/28 21:40, James Morse wrote: > Hi gengdongjiu, > > On 28/03/17 13:16, gengdongjiu wrote: >> On 2017/3/28 19:54, Achin Gupta wrote: >>> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote: >>>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote: >>>>> On the host, part of UEFI is involved to generate the CPER records. >>>>> In a guest?, I don't know. >>>>> Qemu could generate the records, or drive some other component to do it. >>>> >>>> I think I am beginning to understand this a bit. Since the guet UEFI >>>> instance is specifically built for the machine it runs on, QEMU's virt >>>> machine in this case, they could simply agree (by some contract) to >>>> place the records at some specific location in memory, and if the guest >>>> kernel asks its guest UEFI for that location, things should just work by >>>> having logic in QEMU to process error reports and populate guest memory. >>>> >>>> Is this how others see the world too? >>> >>> I think so! >>> >>> AFAIU, the memory where CPERs will reside should be specified in a GHES entry in >>> the HEST. Is this not the case with a guest kernel i.e. the guest UEFI creates a >>> HEST for the guest Kernel? >>> >>> If so, then the question is how the guest UEFI finds out where QEMU (acting as >>> EL3 firmware) will populate the CPERs. This could either be a contract between >>> the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to ask QEMU >>> where the memory is. >> >> whether invoke the guest UEFI will be complex? not see the advantage. it seems x86 Qemu >> directly generate the ACPI table, but I am not sure, we are checking the qemu > logical. >> let Qemu generate CPER record may be clear. > > At boot UEFI in the guest will need to make sure the areas of memory that may be > used for CPER records are reserved. Whether UEFI or Qemu decides where these are > needs deciding, (but probably not here)... > > At runtime, when an error has occurred, I agree it would be simpler (fewer > components involved) if Qemu generates the CPER records. But if UEFI made the > memory choice above they need to interact and it gets complicated again. The > CPER records are defined in the UEFI spec, so I would expect UEFI to contain > code to generate/parse them. > > > Thanks, > > James > > > . > From mboxrd@z Thu Jan 1 00:00:00 1970 From: gengdongjiu Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Wed, 29 Mar 2017 17:36:37 +0800 Message-ID: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> References: <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: kvm@vger.kernel.org, catalin.marinas@arm.com, Achin Gupta , will.deacon@arm.com, wuquanming@huawei.com, wangxiongfeng2@huawei.com, Christoffer Dall , kvmarm@lists.cs.columbia.edu, Leif.Lindholm@linaro.com, huangshaoyu@huawei.com, Marc Zyngier , andre.przywara@arm.com, nd@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org To: , , , , Return-path: In-Reply-To: <58DA67BA.8070404@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org CkhpIExhc3psby9CaWVzaGV1dmVsL1FlbXUgZGV2ZWxvcGVyLAoKICAgTm93IEkgZW5jb3VudGVy IGEgaXNzdWUgYW5kIHdhbnQgdG8gY29uc3VsdCB3aXRoIHlvdSBpbiBBUk02NCBwbGF0Zm9ybe+8 jCBhcyBkZXNjcmliZWQgYmVsb3c6CgogICB3aGVuIGd1ZXN0IE9TIGhhcHBlbiBzeW5jaHJvbm91 cyBvciBhc3luY2hyb25vdXMgYWJvcnQsIGt2bSBuZWVkcyB0byBzZW5kIHRoZSBlcnJvciBhZGRy ZXNzIHRvIFFlbXUgb3IgVUVGSSB0aHJvdWdoIHNpZ2J1cyB0byBkeW5hbWljYWxseSBnZW5lcmF0 ZSBBUEVJIHRhYmxlLiBmcm9tIG15IGludmVzdGlnYXRpb24sIHRoZXJlIGFyZSB0d28gd2F5czoK CiAgICgxKSBRZW11IGdldCB0aGUgZXJyb3IgYWRkcmVzcywgYW5kIGdlbmVyYXRlIHRoZSBBUEVJ IHRhYmxlLCB0aGVuIG5vdGlmeSBVRUZJIHRvIGtub3cgdGhpcyBnZW5lcmF0aW9uLCB0aGVuIGlu amVjdCBhYm9ydCBlcnJvciB0byBndWVzdCBPUywgZ3Vlc3QgT1MgcmVhZCB0aGUgQVBFSSB0YWJs ZS4KICAgKDIpIFFlbXUgZ2V0IHRoZSBlcnJvciBhZGRyZXNzLCBhbmQgbGV0IFVFRkkgdG8gZ2Vu ZXJhdGUgdGhlIEFQRUkgdGFibGUsIHRoZW4gaW5qZWN0IGFib3J0IGVycm9yIHRvIGd1ZXN0IE9T LCBndWVzdCBPUyByZWFkIHRoZSBBUEVJIHRhYmxlLgoKCiAgIERvIHlvdSB0aGluayB3aGljaCBt b2R1bGVzIGdlbmVyYXRlcyB0aGUgQVBFSSB0YWJsZSBpcyBiZXR0ZXI/IFVFRkkgb3IgUWVtdT8K CgoKCk9uIDIwMTcvMy8yOCAyMTo0MCwgSmFtZXMgTW9yc2Ugd3JvdGU6Cj4gSGkgZ2VuZ2Rvbmdq aXUsCj4gCj4gT24gMjgvMDMvMTcgMTM6MTYsIGdlbmdkb25naml1IHdyb3RlOgo+PiBPbiAyMDE3 LzMvMjggMTk6NTQsIEFjaGluIEd1cHRhIHdyb3RlOgo+Pj4gT24gVHVlLCBNYXIgMjgsIDIwMTcg YXQgMDE6MjM6MjhQTSArMDIwMCwgQ2hyaXN0b2ZmZXIgRGFsbCB3cm90ZToKPj4+PiBPbiBUdWUs IE1hciAyOCwgMjAxNyBhdCAxMTo0ODowOEFNICswMTAwLCBKYW1lcyBNb3JzZSB3cm90ZToKPj4+ Pj4gT24gdGhlIGhvc3QsIHBhcnQgb2YgVUVGSSBpcyBpbnZvbHZlZCB0byBnZW5lcmF0ZSB0aGUg Q1BFUiByZWNvcmRzLgo+Pj4+PiBJbiBhIGd1ZXN0PywgSSBkb24ndCBrbm93Lgo+Pj4+PiBRZW11 IGNvdWxkIGdlbmVyYXRlIHRoZSByZWNvcmRzLCBvciBkcml2ZSBzb21lIG90aGVyIGNvbXBvbmVu dCB0byBkbyBpdC4KPj4+Pgo+Pj4+IEkgdGhpbmsgSSBhbSBiZWdpbm5pbmcgdG8gdW5kZXJzdGFu ZCB0aGlzIGEgYml0LiAgU2luY2UgdGhlIGd1ZXQgVUVGSQo+Pj4+IGluc3RhbmNlIGlzIHNwZWNp ZmljYWxseSBidWlsdCBmb3IgdGhlIG1hY2hpbmUgaXQgcnVucyBvbiwgUUVNVSdzIHZpcnQKPj4+ PiBtYWNoaW5lIGluIHRoaXMgY2FzZSwgdGhleSBjb3VsZCBzaW1wbHkgYWdyZWUgKGJ5IHNvbWUg Y29udHJhY3QpIHRvCj4+Pj4gcGxhY2UgdGhlIHJlY29yZHMgYXQgc29tZSBzcGVjaWZpYyBsb2Nh dGlvbiBpbiBtZW1vcnksIGFuZCBpZiB0aGUgZ3Vlc3QKPj4+PiBrZXJuZWwgYXNrcyBpdHMgZ3Vl c3QgVUVGSSBmb3IgdGhhdCBsb2NhdGlvbiwgdGhpbmdzIHNob3VsZCBqdXN0IHdvcmsgYnkKPj4+ PiBoYXZpbmcgbG9naWMgaW4gUUVNVSB0byBwcm9jZXNzIGVycm9yIHJlcG9ydHMgYW5kIHBvcHVs YXRlIGd1ZXN0IG1lbW9yeS4KPj4+Pgo+Pj4+IElzIHRoaXMgaG93IG90aGVycyBzZWUgdGhlIHdv cmxkIHRvbz8KPj4+Cj4+PiBJIHRoaW5rIHNvIQo+Pj4KPj4+IEFGQUlVLCB0aGUgbWVtb3J5IHdo ZXJlIENQRVJzIHdpbGwgcmVzaWRlIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gYSBHSEVTIGVudHJ5 IGluCj4+PiB0aGUgSEVTVC4gSXMgdGhpcyBub3QgdGhlIGNhc2Ugd2l0aCBhIGd1ZXN0IGtlcm5l bCBpLmUuIHRoZSBndWVzdCBVRUZJIGNyZWF0ZXMgYQo+Pj4gSEVTVCBmb3IgdGhlIGd1ZXN0IEtl cm5lbD8KPj4+Cj4+PiBJZiBzbywgdGhlbiB0aGUgcXVlc3Rpb24gaXMgaG93IHRoZSBndWVzdCBV RUZJIGZpbmRzIG91dCB3aGVyZSBRRU1VIChhY3RpbmcgYXMKPj4+IEVMMyBmaXJtd2FyZSkgd2ls bCBwb3B1bGF0ZSB0aGUgQ1BFUnMuIFRoaXMgY291bGQgZWl0aGVyIGJlIGEgY29udHJhY3QgYmV0 d2Vlbgo+Pj4gdGhlIHR3byBvciBhIGd1ZXN0IERYRSBkcml2ZXIgdXNlcyB0aGUgTU1fQ09NTVVO SUNBVEUgY2FsbCAoc2VlIFsxXSkgdG8gYXNrIFFFTVUKPj4+IHdoZXJlIHRoZSBtZW1vcnkgaXMu Cj4+Cj4+IHdoZXRoZXIgaW52b2tlIHRoZSBndWVzdCBVRUZJIHdpbGwgYmUgY29tcGxleD8gbm90 IHNlZSB0aGUgYWR2YW50YWdlLiBpdCBzZWVtcyB4ODYgUWVtdQo+PiBkaXJlY3RseSBnZW5lcmF0 ZSB0aGUgQUNQSSB0YWJsZSwgYnV0IEkgYW0gbm90IHN1cmUsIHdlIGFyZSBjaGVja2luZyB0aGUg cWVtdQo+IGxvZ2ljYWwuCj4+IGxldCBRZW11IGdlbmVyYXRlIENQRVIgcmVjb3JkIG1heSBiZSBj bGVhci4KPiAKPiBBdCBib290IFVFRkkgaW4gdGhlIGd1ZXN0IHdpbGwgbmVlZCB0byBtYWtlIHN1 cmUgdGhlIGFyZWFzIG9mIG1lbW9yeSB0aGF0IG1heSBiZQo+IHVzZWQgZm9yIENQRVIgcmVjb3Jk cyBhcmUgcmVzZXJ2ZWQuIFdoZXRoZXIgVUVGSSBvciBRZW11IGRlY2lkZXMgd2hlcmUgdGhlc2Ug YXJlCj4gbmVlZHMgZGVjaWRpbmcsIChidXQgcHJvYmFibHkgbm90IGhlcmUpLi4uCj4gCj4gQXQg cnVudGltZSwgd2hlbiBhbiBlcnJvciBoYXMgb2NjdXJyZWQsIEkgYWdyZWUgaXQgd291bGQgYmUg c2ltcGxlciAoZmV3ZXIKPiBjb21wb25lbnRzIGludm9sdmVkKSBpZiBRZW11IGdlbmVyYXRlcyB0 aGUgQ1BFUiByZWNvcmRzLiBCdXQgaWYgVUVGSSBtYWRlIHRoZQo+IG1lbW9yeSBjaG9pY2UgYWJv dmUgdGhleSBuZWVkIHRvIGludGVyYWN0IGFuZCBpdCBnZXRzIGNvbXBsaWNhdGVkIGFnYWluLiBU aGUKPiBDUEVSIHJlY29yZHMgYXJlIGRlZmluZWQgaW4gdGhlIFVFRkkgc3BlYywgc28gSSB3b3Vs ZCBleHBlY3QgVUVGSSB0byBjb250YWluCj4gY29kZSB0byBnZW5lcmF0ZS9wYXJzZSB0aGVtLgo+ IAo+IAo+IFRoYW5rcywKPiAKPiBKYW1lcwo+IAo+IAo+IC4KPiAKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmt2bWFybSBtYWlsaW5nIGxpc3QKa3ZtYXJt QGxpc3RzLmNzLmNvbHVtYmlhLmVkdQpodHRwczovL2xpc3RzLmNzLmNvbHVtYmlhLmVkdS9tYWls bWFuL2xpc3RpbmZvL2t2bWFybQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctAQr-00081u-F8 for qemu-devel@nongnu.org; Wed, 29 Mar 2017 06:02:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctAQo-0001k0-Bm for qemu-devel@nongnu.org; Wed, 29 Mar 2017 06:02:25 -0400 Received: from [45.249.212.189] (port=2884 helo=dggrg03-dlp.huawei.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctAQm-0001hQ-Rp for qemu-devel@nongnu.org; Wed, 29 Mar 2017 06:02:22 -0400 References: <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> From: gengdongjiu Message-ID: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> Date: Wed, 29 Mar 2017 17:36:37 +0800 MIME-Version: 1.0 In-Reply-To: <58DA67BA.8070404@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] kvm: pass the virtual SEI syndrome to guest OS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: lersek@redhat.com, ard.biesheuvel@linaro.org, edk2-devel@lists.01.org, qemu-devel@nongnu.org, zhaoshenglong@huawei.com Cc: Achin Gupta , James Morse , Christoffer Dall , xiexiuqi@huawei.com, Marc Zyngier , catalin.marinas@arm.com, will.deacon@arm.com, christoffer.dall@linaro.org, rkrcmar@redhat.com, suzuki.poulose@arm.com, andre.przywara@arm.com, mark.rutland@arm.com, vladimir.murzin@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com, wuquanming@huawei.com, huangshaoyu@huawei.com, Leif.Lindholm@linaro.comnd@arm.com Hi Laszlo/Biesheuvel/Qemu developer, Now I encounter a issue and want to consult with you in ARM64 platform， as described below: when guest OS happen synchronous or asynchronous abort, kvm needs to send the error address to Qemu or UEFI through sigbus to dynamically generate APEI table. from my investigation, there are two ways: (1) Qemu get the error address, and generate the APEI table, then notify UEFI to know this generation, then inject abort error to guest OS, guest OS read the APEI table. (2) Qemu get the error address, and let UEFI to generate the APEI table, then inject abort error to guest OS, guest OS read the APEI table. Do you think which modules generates the APEI table is better? UEFI or Qemu? On 2017/3/28 21:40, James Morse wrote: > Hi gengdongjiu, > > On 28/03/17 13:16, gengdongjiu wrote: >> On 2017/3/28 19:54, Achin Gupta wrote: >>> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote: >>>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote: >>>>> On the host, part of UEFI is involved to generate the CPER records. >>>>> In a guest?, I don't know. >>>>> Qemu could generate the records, or drive some other component to do it. >>>> >>>> I think I am beginning to understand this a bit. Since the guet UEFI >>>> instance is specifically built for the machine it runs on, QEMU's virt >>>> machine in this case, they could simply agree (by some contract) to >>>> place the records at some specific location in memory, and if the guest >>>> kernel asks its guest UEFI for that location, things should just work by >>>> having logic in QEMU to process error reports and populate guest memory. >>>> >>>> Is this how others see the world too? >>> >>> I think so! >>> >>> AFAIU, the memory where CPERs will reside should be specified in a GHES entry in >>> the HEST. Is this not the case with a guest kernel i.e. the guest UEFI creates a >>> HEST for the guest Kernel? >>> >>> If so, then the question is how the guest UEFI finds out where QEMU (acting as >>> EL3 firmware) will populate the CPERs. This could either be a contract between >>> the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to ask QEMU >>> where the memory is. >> >> whether invoke the guest UEFI will be complex? not see the advantage. it seems x86 Qemu >> directly generate the ACPI table, but I am not sure, we are checking the qemu > logical. >> let Qemu generate CPER record may be clear. > > At boot UEFI in the guest will need to make sure the areas of memory that may be > used for CPER records are reserved. Whether UEFI or Qemu decides where these are > needs deciding, (but probably not here)... > > At runtime, when an error has occurred, I agree it would be simpler (fewer > components involved) if Qemu generates the CPER records. But if UEFI made the > memory choice above they need to interact and it gets complicated again. The > CPER records are defined in the UEFI spec, so I would expect UEFI to contain > code to generate/parse them. > > > Thanks, > > James > > > . > From mboxrd@z Thu Jan 1 00:00:00 1970 From: gengdongjiu Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Wed, 29 Mar 2017 17:36:37 +0800 Message-ID: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> References: <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5405240A63 for ; Wed, 29 Mar 2017 05:35:48 -0400 (EDT) Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhxQ7ndwek98 for ; Wed, 29 Mar 2017 05:35:47 -0400 (EDT) Received: from dggrg03-dlp.huawei.com (unknown [45.249.212.189]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 72CC9408EB for ; Wed, 29 Mar 2017 05:35:45 -0400 (EDT) In-Reply-To: <58DA67BA.8070404@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: lersek@redhat.com, ard.biesheuvel@linaro.org, edk2-devel@lists.01.org, qemu-devel@nongnu.org, zhaoshenglong@huawei.com Cc: kvm@vger.kernel.org, catalin.marinas@arm.com, Achin Gupta , will.deacon@arm.com, wuquanming@huawei.com, wangxiongfeng2@huawei.com, Christoffer Dall , kvmarm@lists.cs.columbia.edu, Leif.Lindholm@linaro.com, huangshaoyu@huawei.com, Marc Zyngier , andre.przywara@arm.com, nd@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org List-Id: kvmarm@lists.cs.columbia.edu CkhpIExhc3psby9CaWVzaGV1dmVsL1FlbXUgZGV2ZWxvcGVyLAoKICAgTm93IEkgZW5jb3VudGVy IGEgaXNzdWUgYW5kIHdhbnQgdG8gY29uc3VsdCB3aXRoIHlvdSBpbiBBUk02NCBwbGF0Zm9ybe+8 jCBhcyBkZXNjcmliZWQgYmVsb3c6CgogICB3aGVuIGd1ZXN0IE9TIGhhcHBlbiBzeW5jaHJvbm91 cyBvciBhc3luY2hyb25vdXMgYWJvcnQsIGt2bSBuZWVkcyB0byBzZW5kIHRoZSBlcnJvciBhZGRy ZXNzIHRvIFFlbXUgb3IgVUVGSSB0aHJvdWdoIHNpZ2J1cyB0byBkeW5hbWljYWxseSBnZW5lcmF0 ZSBBUEVJIHRhYmxlLiBmcm9tIG15IGludmVzdGlnYXRpb24sIHRoZXJlIGFyZSB0d28gd2F5czoK CiAgICgxKSBRZW11IGdldCB0aGUgZXJyb3IgYWRkcmVzcywgYW5kIGdlbmVyYXRlIHRoZSBBUEVJ IHRhYmxlLCB0aGVuIG5vdGlmeSBVRUZJIHRvIGtub3cgdGhpcyBnZW5lcmF0aW9uLCB0aGVuIGlu amVjdCBhYm9ydCBlcnJvciB0byBndWVzdCBPUywgZ3Vlc3QgT1MgcmVhZCB0aGUgQVBFSSB0YWJs ZS4KICAgKDIpIFFlbXUgZ2V0IHRoZSBlcnJvciBhZGRyZXNzLCBhbmQgbGV0IFVFRkkgdG8gZ2Vu ZXJhdGUgdGhlIEFQRUkgdGFibGUsIHRoZW4gaW5qZWN0IGFib3J0IGVycm9yIHRvIGd1ZXN0IE9T LCBndWVzdCBPUyByZWFkIHRoZSBBUEVJIHRhYmxlLgoKCiAgIERvIHlvdSB0aGluayB3aGljaCBt b2R1bGVzIGdlbmVyYXRlcyB0aGUgQVBFSSB0YWJsZSBpcyBiZXR0ZXI/IFVFRkkgb3IgUWVtdT8K CgoKCk9uIDIwMTcvMy8yOCAyMTo0MCwgSmFtZXMgTW9yc2Ugd3JvdGU6Cj4gSGkgZ2VuZ2Rvbmdq aXUsCj4gCj4gT24gMjgvMDMvMTcgMTM6MTYsIGdlbmdkb25naml1IHdyb3RlOgo+PiBPbiAyMDE3 LzMvMjggMTk6NTQsIEFjaGluIEd1cHRhIHdyb3RlOgo+Pj4gT24gVHVlLCBNYXIgMjgsIDIwMTcg YXQgMDE6MjM6MjhQTSArMDIwMCwgQ2hyaXN0b2ZmZXIgRGFsbCB3cm90ZToKPj4+PiBPbiBUdWUs IE1hciAyOCwgMjAxNyBhdCAxMTo0ODowOEFNICswMTAwLCBKYW1lcyBNb3JzZSB3cm90ZToKPj4+ Pj4gT24gdGhlIGhvc3QsIHBhcnQgb2YgVUVGSSBpcyBpbnZvbHZlZCB0byBnZW5lcmF0ZSB0aGUg Q1BFUiByZWNvcmRzLgo+Pj4+PiBJbiBhIGd1ZXN0PywgSSBkb24ndCBrbm93Lgo+Pj4+PiBRZW11 IGNvdWxkIGdlbmVyYXRlIHRoZSByZWNvcmRzLCBvciBkcml2ZSBzb21lIG90aGVyIGNvbXBvbmVu dCB0byBkbyBpdC4KPj4+Pgo+Pj4+IEkgdGhpbmsgSSBhbSBiZWdpbm5pbmcgdG8gdW5kZXJzdGFu ZCB0aGlzIGEgYml0LiAgU2luY2UgdGhlIGd1ZXQgVUVGSQo+Pj4+IGluc3RhbmNlIGlzIHNwZWNp ZmljYWxseSBidWlsdCBmb3IgdGhlIG1hY2hpbmUgaXQgcnVucyBvbiwgUUVNVSdzIHZpcnQKPj4+ PiBtYWNoaW5lIGluIHRoaXMgY2FzZSwgdGhleSBjb3VsZCBzaW1wbHkgYWdyZWUgKGJ5IHNvbWUg Y29udHJhY3QpIHRvCj4+Pj4gcGxhY2UgdGhlIHJlY29yZHMgYXQgc29tZSBzcGVjaWZpYyBsb2Nh dGlvbiBpbiBtZW1vcnksIGFuZCBpZiB0aGUgZ3Vlc3QKPj4+PiBrZXJuZWwgYXNrcyBpdHMgZ3Vl c3QgVUVGSSBmb3IgdGhhdCBsb2NhdGlvbiwgdGhpbmdzIHNob3VsZCBqdXN0IHdvcmsgYnkKPj4+ PiBoYXZpbmcgbG9naWMgaW4gUUVNVSB0byBwcm9jZXNzIGVycm9yIHJlcG9ydHMgYW5kIHBvcHVs YXRlIGd1ZXN0IG1lbW9yeS4KPj4+Pgo+Pj4+IElzIHRoaXMgaG93IG90aGVycyBzZWUgdGhlIHdv cmxkIHRvbz8KPj4+Cj4+PiBJIHRoaW5rIHNvIQo+Pj4KPj4+IEFGQUlVLCB0aGUgbWVtb3J5IHdo ZXJlIENQRVJzIHdpbGwgcmVzaWRlIHNob3VsZCBiZSBzcGVjaWZpZWQgaW4gYSBHSEVTIGVudHJ5 IGluCj4+PiB0aGUgSEVTVC4gSXMgdGhpcyBub3QgdGhlIGNhc2Ugd2l0aCBhIGd1ZXN0IGtlcm5l bCBpLmUuIHRoZSBndWVzdCBVRUZJIGNyZWF0ZXMgYQo+Pj4gSEVTVCBmb3IgdGhlIGd1ZXN0IEtl cm5lbD8KPj4+Cj4+PiBJZiBzbywgdGhlbiB0aGUgcXVlc3Rpb24gaXMgaG93IHRoZSBndWVzdCBV RUZJIGZpbmRzIG91dCB3aGVyZSBRRU1VIChhY3RpbmcgYXMKPj4+IEVMMyBmaXJtd2FyZSkgd2ls bCBwb3B1bGF0ZSB0aGUgQ1BFUnMuIFRoaXMgY291bGQgZWl0aGVyIGJlIGEgY29udHJhY3QgYmV0 d2Vlbgo+Pj4gdGhlIHR3byBvciBhIGd1ZXN0IERYRSBkcml2ZXIgdXNlcyB0aGUgTU1fQ09NTVVO SUNBVEUgY2FsbCAoc2VlIFsxXSkgdG8gYXNrIFFFTVUKPj4+IHdoZXJlIHRoZSBtZW1vcnkgaXMu Cj4+Cj4+IHdoZXRoZXIgaW52b2tlIHRoZSBndWVzdCBVRUZJIHdpbGwgYmUgY29tcGxleD8gbm90 IHNlZSB0aGUgYWR2YW50YWdlLiBpdCBzZWVtcyB4ODYgUWVtdQo+PiBkaXJlY3RseSBnZW5lcmF0 ZSB0aGUgQUNQSSB0YWJsZSwgYnV0IEkgYW0gbm90IHN1cmUsIHdlIGFyZSBjaGVja2luZyB0aGUg cWVtdQo+IGxvZ2ljYWwuCj4+IGxldCBRZW11IGdlbmVyYXRlIENQRVIgcmVjb3JkIG1heSBiZSBj bGVhci4KPiAKPiBBdCBib290IFVFRkkgaW4gdGhlIGd1ZXN0IHdpbGwgbmVlZCB0byBtYWtlIHN1 cmUgdGhlIGFyZWFzIG9mIG1lbW9yeSB0aGF0IG1heSBiZQo+IHVzZWQgZm9yIENQRVIgcmVjb3Jk cyBhcmUgcmVzZXJ2ZWQuIFdoZXRoZXIgVUVGSSBvciBRZW11IGRlY2lkZXMgd2hlcmUgdGhlc2Ug YXJlCj4gbmVlZHMgZGVjaWRpbmcsIChidXQgcHJvYmFibHkgbm90IGhlcmUpLi4uCj4gCj4gQXQg cnVudGltZSwgd2hlbiBhbiBlcnJvciBoYXMgb2NjdXJyZWQsIEkgYWdyZWUgaXQgd291bGQgYmUg c2ltcGxlciAoZmV3ZXIKPiBjb21wb25lbnRzIGludm9sdmVkKSBpZiBRZW11IGdlbmVyYXRlcyB0 aGUgQ1BFUiByZWNvcmRzLiBCdXQgaWYgVUVGSSBtYWRlIHRoZQo+IG1lbW9yeSBjaG9pY2UgYWJv dmUgdGhleSBuZWVkIHRvIGludGVyYWN0IGFuZCBpdCBnZXRzIGNvbXBsaWNhdGVkIGFnYWluLiBU aGUKPiBDUEVSIHJlY29yZHMgYXJlIGRlZmluZWQgaW4gdGhlIFVFRkkgc3BlYywgc28gSSB3b3Vs ZCBleHBlY3QgVUVGSSB0byBjb250YWluCj4gY29kZSB0byBnZW5lcmF0ZS9wYXJzZSB0aGVtLgo+ IAo+IAo+IFRoYW5rcywKPiAKPiBKYW1lcwo+IAo+IAo+IC4KPiAKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmt2bWFybSBtYWlsaW5nIGxpc3QKa3ZtYXJt QGxpc3RzLmNzLmNvbHVtYmlhLmVkdQpodHRwczovL2xpc3RzLmNzLmNvbHVtYmlhLmVkdS9tYWls bWFuL2xpc3RpbmZvL2t2bWFybQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: gengdongjiu@huawei.com (gengdongjiu) Date: Wed, 29 Mar 2017 17:36:37 +0800 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <58DA67BA.8070404@arm.com> References: <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> Message-ID: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Laszlo/Biesheuvel/Qemu developer, Now I encounter a issue and want to consult with you in ARM64 platform? as described below: when guest OS happen synchronous or asynchronous abort, kvm needs to send the error address to Qemu or UEFI through sigbus to dynamically generate APEI table. from my investigation, there are two ways: (1) Qemu get the error address, and generate the APEI table, then notify UEFI to know this generation, then inject abort error to guest OS, guest OS read the APEI table. (2) Qemu get the error address, and let UEFI to generate the APEI table, then inject abort error to guest OS, guest OS read the APEI table. Do you think which modules generates the APEI table is better? UEFI or Qemu? On 2017/3/28 21:40, James Morse wrote: > Hi gengdongjiu, > > On 28/03/17 13:16, gengdongjiu wrote: >> On 2017/3/28 19:54, Achin Gupta wrote: >>> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote: >>>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote: >>>>> On the host, part of UEFI is involved to generate the CPER records. >>>>> In a guest?, I don't know. >>>>> Qemu could generate the records, or drive some other component to do it. >>>> >>>> I think I am beginning to understand this a bit. Since the guet UEFI >>>> instance is specifically built for the machine it runs on, QEMU's virt >>>> machine in this case, they could simply agree (by some contract) to >>>> place the records at some specific location in memory, and if the guest >>>> kernel asks its guest UEFI for that location, things should just work by >>>> having logic in QEMU to process error reports and populate guest memory. >>>> >>>> Is this how others see the world too? >>> >>> I think so! >>> >>> AFAIU, the memory where CPERs will reside should be specified in a GHES entry in >>> the HEST. Is this not the case with a guest kernel i.e. the guest UEFI creates a >>> HEST for the guest Kernel? >>> >>> If so, then the question is how the guest UEFI finds out where QEMU (acting as >>> EL3 firmware) will populate the CPERs. This could either be a contract between >>> the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to ask QEMU >>> where the memory is. >> >> whether invoke the guest UEFI will be complex? not see the advantage. it seems x86 Qemu >> directly generate the ACPI table, but I am not sure, we are checking the qemu > logical. >> let Qemu generate CPER record may be clear. > > At boot UEFI in the guest will need to make sure the areas of memory that may be > used for CPER records are reserved. Whether UEFI or Qemu decides where these are > needs deciding, (but probably not here)... > > At runtime, when an error has occurred, I agree it would be simpler (fewer > components involved) if Qemu generates the CPER records. But if UEFI made the > memory choice above they need to interact and it gets complicated again. The > CPER records are defined in the UEFI spec, so I would expect UEFI to contain > code to generate/parse them. > > > Thanks, > > James > > > . >