From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1039966AbdDUN3B (ORCPT ); Fri, 21 Apr 2017 09:29:01 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:5449 "EHLO dggrg03-dlp.huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1039291AbdDUN26 (ORCPT ); Fri, 21 Apr 2017 09:28:58 -0400 Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS To: Laszlo Ersek , Achin Gupta References: <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> <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> <20170329103658.GQ23682@e104320-lin> <2a427164-9b37-6711-3a56-906634ba7f12@redhat.com> <7c5c8ab7-8fcc-1c98-0bc1-cccb66c4c84d@huawei.com> <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> CC: , , , , James Morse , Christoffer Dall , , Marc Zyngier , , , , , , , , , , , , , , , , , , Michael Tsirkin , Igor Mammedov From: gengdongjiu Message-ID: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Date: Fri, 21 Apr 2017 21:27:31 +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: <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.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.0A020202.58FA08E0.01EF,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 all/Laszlo, sorry, I have a question to consult with you. On 2017/4/7 2:55, Laszlo Ersek wrote: > On 04/06/17 14:35, gengdongjiu wrote: >> Dear, Laszlo >> Thanks for your detailed explanation. >> >> On 2017/3/29 19:58, Laszlo Ersek wrote: >>> (This ought to be one of the longest address lists I've ever seen :) >>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>> measure, I'm adding MST and Igor.) >>> >>> On 03/29/17 12:36, Achin Gupta wrote: >>>> Hi gengdongjiu, >>>> >>>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote: >>>>> >>>>> 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. >>>> >>>> Just being pedantic! I don't think we are talking about creating the APEI table >>>> dynamically here. The issue is: Once KVM has received an error that is destined >>>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the error >>>> into the guest OS, a CPER (Common Platform Error Record) has to be generated >>>> corresponding to the error source (GHES corresponding to memory subsystem, >>>> processor etc) to allow the guest OS to do anything meaningful with the >>>> error. So who should create the CPER is the question. >>>> >>>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error arrives >>>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is >>>> responsible for creating the CPER. ARM is experimenting with using a Standalone >>>> MM EDK2 image in the secure world to do the CPER creation. This will avoid >>>> adding the same code in ARM TF in EL3 (better for security). The error will then >>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted >>>> Firmware. >>>> >>>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1 >>>> interface (as discussed with Christoffer below). So it should generate the CPER >>>> before injecting the error. >>>> >>>> This is corresponds to (1) above apart from notifying UEFI (I am assuming you >>>> mean guest UEFI). At this time, the guest OS already knows where to pick up the >>>> CPER from through the HEST. Qemu has to create the CPER and populate its address >>>> at the address exported in the HEST. Guest UEFI should not be involved in this >>>> flow. Its job was to create the HEST at boot and that has been done by this >>>> stage. >>>> >>>> Qemu folk will be able to add but it looks like support for CPER generation will >>>> need to be added to Qemu. We need to resolve this. >>>> >>>> Do shout if I am missing anything above. >>> >>> After reading this email, the use case looks *very* similar to what >>> we've just done with VMGENID for QEMU 2.9. >>> >>> We have a facility between QEMU and the guest firmware, called "ACPI >>> linker/loader", with which QEMU instructs the firmware to >>> >>> - allocate and download blobs into guest RAM (AcpiNVS type memory) -- >>> ALLOCATE command, >>> >>> - relocate pointers in those blobs, to fields in other (or the same) >>> blobs -- ADD_POINTER command, >>> >>> - set ACPI table checksums -- ADD_CHECKSUM command, >>> >>> - and send GPAs of fields within such blobs back to QEMU -- >>> WRITE_POINTER command. >>> >>> This is how I imagine we can map the facility to the current use case >>> (note that this is the first time I read about HEST / GHES / CPER): Laszlo lists a Qemu GHES table generation solution, Mainly use the four commands: "ALLOCATE/ADD_POINTER/ADD_CHECKSUM/WRITE_POINTER" to communicate with BIOS so whether the four commands needs to be supported by the guest firware/UEFI. I found the "WRITE_POINTER" always failed. so I suspect guest UEFI/firmware not support the "WRITE_POINTER" command. please help me confirm it, thanks so much. From mboxrd@z Thu Jan 1 00:00:00 1970 From: gengdongjiu Subject: Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Fri, 21 Apr 2017 21:27:31 +0800 Message-ID: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> References: <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> <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> <20170329103658.GQ23682@e104320-lin> <2a427164-9b37-6711-3a56-906634ba7f12@redhat.com> <7c5c8ab7-8fcc-1c98-0bc1-cccb66c4c84d@huawei.com> <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: Michael Tsirkin , kvm@vger.kernel.org, rkrcmar@redhat.com, catalin.marinas@arm.com, will.deacon@arm.com, qemu-devel@nongnu.org, wuquanming@huawei.com, wangxiongfeng2@huawei.com, Christoffer Dall , suzuki.poulose@arm.com, kvmarm@lists.cs.columbia.edu, Leif.Lindholm@linaro.com, huangshaoyu@huawei.com, vladimir.murzin@arm.com, xiexiuqi@huawei.com, Marc Zyngier , andre.przywara@arm.com, edk2-devel@lists.01.org, nd@arm.com, linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, James Morse , christoffer.dall@linaro.org To: Laszlo Ersek , Achin Gupta Return-path: In-Reply-To: <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" List-Id: kvm.vger.kernel.org SGkgYWxsL0xhc3psbywKCiAgc29ycnksIEkgaGF2ZSBhIHF1ZXN0aW9uIHRvIGNvbnN1bHQgd2l0 aCB5b3UuCgoKT24gMjAxNy80LzcgMjo1NSwgTGFzemxvIEVyc2VrIHdyb3RlOgo+IE9uIDA0LzA2 LzE3IDE0OjM1LCBnZW5nZG9uZ2ppdSB3cm90ZToKPj4gRGVhciwgTGFzemxvCj4+ICAgIFRoYW5r cyBmb3IgeW91ciBkZXRhaWxlZCBleHBsYW5hdGlvbi4KPj4KPj4gT24gMjAxNy8zLzI5IDE5OjU4 LCBMYXN6bG8gRXJzZWsgd3JvdGU6Cj4+PiAoVGhpcyBvdWdodCB0byBiZSBvbmUgb2YgdGhlIGxv bmdlc3QgYWRkcmVzcyBsaXN0cyBJJ3ZlIGV2ZXIgc2VlbiA6KQo+Pj4gVGhhbmtzIGZvciB0aGUg Q0MuIEknbSBnbGFkIFNoYW5ub24gaXMgYWxyZWFkeSBvbiB0aGUgQ0MgbGlzdC4gRm9yIGdvb2QK Pj4+IG1lYXN1cmUsIEknbSBhZGRpbmcgTVNUIGFuZCBJZ29yLikKPj4+Cj4+PiBPbiAwMy8yOS8x NyAxMjozNiwgQWNoaW4gR3VwdGEgd3JvdGU6Cj4+Pj4gSGkgZ2VuZ2RvbmdqaXUsCj4+Pj4KPj4+ PiBPbiBXZWQsIE1hciAyOSwgMjAxNyBhdCAwNTozNjozN1BNICswODAwLCBnZW5nZG9uZ2ppdSB3 cm90ZToKPj4+Pj4KPj4+Pj4gSGkgTGFzemxvL0JpZXNoZXV2ZWwvUWVtdSBkZXZlbG9wZXIsCj4+ Pj4+Cj4+Pj4+ICAgIE5vdyBJIGVuY291bnRlciBhIGlzc3VlIGFuZCB3YW50IHRvIGNvbnN1bHQg d2l0aCB5b3UgaW4gQVJNNjQgcGxhdGZvcm3vvIwgYXMgZGVzY3JpYmVkIGJlbG93Ogo+Pj4+Pgo+ Pj4+PiB3aGVuIGd1ZXN0IE9TIGhhcHBlbiBzeW5jaHJvbm91cyBvciBhc3luY2hyb25vdXMgYWJv cnQsIGt2bSBuZWVkcwo+Pj4+PiB0byBzZW5kIHRoZSBlcnJvciBhZGRyZXNzIHRvIFFlbXUgb3Ig VUVGSSB0aHJvdWdoIHNpZ2J1cyB0bwo+Pj4+PiBkeW5hbWljYWxseSBnZW5lcmF0ZSBBUEVJIHRh YmxlLiBmcm9tIG15IGludmVzdGlnYXRpb24sIHRoZXJlIGFyZQo+Pj4+PiB0d28gd2F5czoKPj4+ Pj4KPj4+Pj4gKDEpIFFlbXUgZ2V0IHRoZSBlcnJvciBhZGRyZXNzLCBhbmQgZ2VuZXJhdGUgdGhl IEFQRUkgdGFibGUsIHRoZW4KPj4+Pj4gbm90aWZ5IFVFRkkgdG8ga25vdyB0aGlzIGdlbmVyYXRp b24sIHRoZW4gaW5qZWN0IGFib3J0IGVycm9yIHRvCj4+Pj4+IGd1ZXN0IE9TLCBndWVzdCBPUyBy ZWFkIHRoZSBBUEVJIHRhYmxlLgo+Pj4+PiAoMikgUWVtdSBnZXQgdGhlIGVycm9yIGFkZHJlc3Ms IGFuZCBsZXQgVUVGSSB0byBnZW5lcmF0ZSB0aGUgQVBFSQo+Pj4+PiB0YWJsZSwgdGhlbiBpbmpl Y3QgYWJvcnQgZXJyb3IgdG8gZ3Vlc3QgT1MsIGd1ZXN0IE9TIHJlYWQgdGhlIEFQRUkKPj4+Pj4g dGFibGUuCj4+Pj4KPj4+PiBKdXN0IGJlaW5nIHBlZGFudGljISBJIGRvbid0IHRoaW5rIHdlIGFy ZSB0YWxraW5nIGFib3V0IGNyZWF0aW5nIHRoZSBBUEVJIHRhYmxlCj4+Pj4gZHluYW1pY2FsbHkg aGVyZS4gVGhlIGlzc3VlIGlzOiBPbmNlIEtWTSBoYXMgcmVjZWl2ZWQgYW4gZXJyb3IgdGhhdCBp cyBkZXN0aW5lZAo+Pj4+IGZvciBhIGd1ZXN0IGl0IHdpbGwgcmFpc2UgYSBTSUdCVVMgdG8gUWVt dS4gTm93IGJlZm9yZSBRZW11IGNhbiBpbmplY3QgdGhlIGVycm9yCj4+Pj4gaW50byB0aGUgZ3Vl c3QgT1MsIGEgQ1BFUiAoQ29tbW9uIFBsYXRmb3JtIEVycm9yIFJlY29yZCkgaGFzIHRvIGJlIGdl bmVyYXRlZAo+Pj4+IGNvcnJlc3BvbmRpbmcgdG8gdGhlIGVycm9yIHNvdXJjZSAoR0hFUyBjb3Jy ZXNwb25kaW5nIHRvIG1lbW9yeSBzdWJzeXN0ZW0sCj4+Pj4gcHJvY2Vzc29yIGV0YykgdG8gYWxs b3cgdGhlIGd1ZXN0IE9TIHRvIGRvIGFueXRoaW5nIG1lYW5pbmdmdWwgd2l0aCB0aGUKPj4+PiBl cnJvci4gU28gd2hvIHNob3VsZCBjcmVhdGUgdGhlIENQRVIgaXMgdGhlIHF1ZXN0aW9uLgo+Pj4+ Cj4+Pj4gQXQgdGhlIEVMMy9FTDIgaW50ZXJmYWNlIChTZWN1cmUgRmlybXdhcmUgYW5kIE9TL0h5 cGVydmlzb3IpLCBhbiBlcnJvciBhcnJpdmVzCj4+Pj4gYXQgRUwzIGFuZCBzZWN1cmUgZmlybXdh cmUgKGF0IEVMMyBvciBhIGxvd2VyIHNlY3VyZSBleGNlcHRpb24gbGV2ZWwpIGlzCj4+Pj4gcmVz cG9uc2libGUgZm9yIGNyZWF0aW5nIHRoZSBDUEVSLiBBUk0gaXMgZXhwZXJpbWVudGluZyB3aXRo IHVzaW5nIGEgU3RhbmRhbG9uZQo+Pj4+IE1NIEVESzIgaW1hZ2UgaW4gdGhlIHNlY3VyZSB3b3Js ZCB0byBkbyB0aGUgQ1BFUiBjcmVhdGlvbi4gVGhpcyB3aWxsIGF2b2lkCj4+Pj4gYWRkaW5nIHRo ZSBzYW1lIGNvZGUgaW4gQVJNIFRGIGluIEVMMyAoYmV0dGVyIGZvciBzZWN1cml0eSkuIFRoZSBl cnJvciB3aWxsIHRoZW4KPj4+PiBiZSBpbmplY3RlZCBpbnRvIHRoZSBPUy9IeXBlcnZpc29yICh0 aHJvdWdoIFNFQS9TRUkvU0RFSSkgdGhyb3VnaCBBUk0gVHJ1c3RlZAo+Pj4+IEZpcm13YXJlLgo+ Pj4+Cj4+Pj4gUWVtdSBpcyBlc3NlbnRpYWxseSBmdWxmaWxsaW5nIHRoZSByb2xlIG9mIHNlY3Vy ZSBmaXJtd2FyZSBhdCB0aGUgRUwyL0VMMQo+Pj4+IGludGVyZmFjZSAoYXMgZGlzY3Vzc2VkIHdp dGggQ2hyaXN0b2ZmZXIgYmVsb3cpLiBTbyBpdCBzaG91bGQgZ2VuZXJhdGUgdGhlIENQRVIKPj4+ PiBiZWZvcmUgaW5qZWN0aW5nIHRoZSBlcnJvci4KPj4+Pgo+Pj4+IFRoaXMgaXMgY29ycmVzcG9u ZHMgdG8gKDEpIGFib3ZlIGFwYXJ0IGZyb20gbm90aWZ5aW5nIFVFRkkgKEkgYW0gYXNzdW1pbmcg eW91Cj4+Pj4gbWVhbiBndWVzdCBVRUZJKS4gQXQgdGhpcyB0aW1lLCB0aGUgZ3Vlc3QgT1MgYWxy ZWFkeSBrbm93cyB3aGVyZSB0byBwaWNrIHVwIHRoZQo+Pj4+IENQRVIgZnJvbSB0aHJvdWdoIHRo ZSBIRVNULiBRZW11IGhhcyB0byBjcmVhdGUgdGhlIENQRVIgYW5kIHBvcHVsYXRlIGl0cyBhZGRy ZXNzCj4+Pj4gYXQgdGhlIGFkZHJlc3MgZXhwb3J0ZWQgaW4gdGhlIEhFU1QuIEd1ZXN0IFVFRkkg c2hvdWxkIG5vdCBiZSBpbnZvbHZlZCBpbiB0aGlzCj4+Pj4gZmxvdy4gSXRzIGpvYiB3YXMgdG8g Y3JlYXRlIHRoZSBIRVNUIGF0IGJvb3QgYW5kIHRoYXQgaGFzIGJlZW4gZG9uZSBieSB0aGlzCj4+ Pj4gc3RhZ2UuCj4+Pj4KPj4+PiBRZW11IGZvbGsgd2lsbCBiZSBhYmxlIHRvIGFkZCBidXQgaXQg bG9va3MgbGlrZSBzdXBwb3J0IGZvciBDUEVSIGdlbmVyYXRpb24gd2lsbAo+Pj4+IG5lZWQgdG8g YmUgYWRkZWQgdG8gUWVtdS4gV2UgbmVlZCB0byByZXNvbHZlIHRoaXMuCj4+Pj4KPj4+PiBEbyBz aG91dCBpZiBJIGFtIG1pc3NpbmcgYW55dGhpbmcgYWJvdmUuCj4+Pgo+Pj4gQWZ0ZXIgcmVhZGlu ZyB0aGlzIGVtYWlsLCB0aGUgdXNlIGNhc2UgbG9va3MgKnZlcnkqIHNpbWlsYXIgdG8gd2hhdAo+ Pj4gd2UndmUganVzdCBkb25lIHdpdGggVk1HRU5JRCBmb3IgUUVNVSAyLjkuCj4+Pgo+Pj4gV2Ug aGF2ZSBhIGZhY2lsaXR5IGJldHdlZW4gUUVNVSBhbmQgdGhlIGd1ZXN0IGZpcm13YXJlLCBjYWxs ZWQgIkFDUEkKPj4+IGxpbmtlci9sb2FkZXIiLCB3aXRoIHdoaWNoIFFFTVUgaW5zdHJ1Y3RzIHRo ZSBmaXJtd2FyZSB0bwo+Pj4KPj4+IC0gYWxsb2NhdGUgYW5kIGRvd25sb2FkIGJsb2JzIGludG8g Z3Vlc3QgUkFNIChBY3BpTlZTIHR5cGUgbWVtb3J5KSAtLQo+Pj4gQUxMT0NBVEUgY29tbWFuZCwK Pj4+Cj4+PiAtIHJlbG9jYXRlIHBvaW50ZXJzIGluIHRob3NlIGJsb2JzLCB0byBmaWVsZHMgaW4g b3RoZXIgKG9yIHRoZSBzYW1lKQo+Pj4gYmxvYnMgLS0gQUREX1BPSU5URVIgY29tbWFuZCwKPj4+ Cj4+PiAtIHNldCBBQ1BJIHRhYmxlIGNoZWNrc3VtcyAtLSBBRERfQ0hFQ0tTVU0gY29tbWFuZCwK Pj4+Cj4+PiAtIGFuZCBzZW5kIEdQQXMgb2YgZmllbGRzIHdpdGhpbiBzdWNoIGJsb2JzIGJhY2sg dG8gUUVNVSAtLQo+Pj4gV1JJVEVfUE9JTlRFUiBjb21tYW5kLgo+Pj4KPj4+IFRoaXMgaXMgaG93 IEkgaW1hZ2luZSB3ZSBjYW4gbWFwIHRoZSBmYWNpbGl0eSB0byB0aGUgY3VycmVudCB1c2UgY2Fz ZQo+Pj4gKG5vdGUgdGhhdCB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lIEkgcmVhZCBhYm91dCBIRVNU IC8gR0hFUyAvIENQRVIpOgoKTGFzemxvIGxpc3RzIGEgUWVtdSBHSEVTIHRhYmxlIGdlbmVyYXRp b24gc29sdXRpb24sIE1haW5seSB1c2UgdGhlIGZvdXIgY29tbWFuZHM6ICJBTExPQ0FURS9BRERf UE9JTlRFUi9BRERfQ0hFQ0tTVU0vV1JJVEVfUE9JTlRFUiIgdG8gY29tbXVuaWNhdGUgd2l0aCBC SU9TCnNvIHdoZXRoZXIgdGhlIGZvdXIgY29tbWFuZHMgbmVlZHMgdG8gYmUgc3VwcG9ydGVkIGJ5 IHRoZSBndWVzdCBmaXJ3YXJlL1VFRkkuICBJIGZvdW5kIHRoZSAgIldSSVRFX1BPSU5URVIiIGFs d2F5cyBmYWlsZWQuIHNvIEkgc3VzcGVjdCBndWVzdCBVRUZJL2Zpcm13YXJlIG5vdCBzdXBwb3J0 IHRoZSAiV1JJVEVfUE9JTlRFUiIgY29tbWFuZC4gcGxlYXNlIGhlbHAgbWUgY29uZmlybSBpdCwg dGhhbmtzIHNvIG11Y2guCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KZWRrMi1kZXZlbCBtYWlsaW5nIGxpc3QKZWRrMi1kZXZlbEBsaXN0cy4wMS5vcmcK aHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9lZGsyLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1YcC-0004hw-C6 for qemu-devel@nongnu.org; Fri, 21 Apr 2017 09:28:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1Yc9-0004Op-4M for qemu-devel@nongnu.org; Fri, 21 Apr 2017 09:28:48 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:3390 helo=dggrg03-dlp.huawei.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1Yc8-0004Ma-9F for qemu-devel@nongnu.org; Fri, 21 Apr 2017 09:28:45 -0400 References: <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> <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> <20170329103658.GQ23682@e104320-lin> <2a427164-9b37-6711-3a56-906634ba7f12@redhat.com> <7c5c8ab7-8fcc-1c98-0bc1-cccb66c4c84d@huawei.com> <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> From: gengdongjiu Message-ID: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Date: Fri, 21 Apr 2017 21:27:31 +0800 MIME-Version: 1.0 In-Reply-To: <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.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: Laszlo Ersek , Achin Gupta Cc: ard.biesheuvel@linaro.org, edk2-devel@lists.01.org, qemu-devel@nongnu.org, zhaoshenglong@huawei.com, 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, Michael Tsirkin , Igor Mammedov Hi all/Laszlo, sorry, I have a question to consult with you. On 2017/4/7 2:55, Laszlo Ersek wrote: > On 04/06/17 14:35, gengdongjiu wrote: >> Dear, Laszlo >> Thanks for your detailed explanation. >> >> On 2017/3/29 19:58, Laszlo Ersek wrote: >>> (This ought to be one of the longest address lists I've ever seen :) >>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>> measure, I'm adding MST and Igor.) >>> >>> On 03/29/17 12:36, Achin Gupta wrote: >>>> Hi gengdongjiu, >>>> >>>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote: >>>>> >>>>> 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. >>>> >>>> Just being pedantic! I don't think we are talking about creating the APEI table >>>> dynamically here. The issue is: Once KVM has received an error that is destined >>>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the error >>>> into the guest OS, a CPER (Common Platform Error Record) has to be generated >>>> corresponding to the error source (GHES corresponding to memory subsystem, >>>> processor etc) to allow the guest OS to do anything meaningful with the >>>> error. So who should create the CPER is the question. >>>> >>>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error arrives >>>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is >>>> responsible for creating the CPER. ARM is experimenting with using a Standalone >>>> MM EDK2 image in the secure world to do the CPER creation. This will avoid >>>> adding the same code in ARM TF in EL3 (better for security). The error will then >>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted >>>> Firmware. >>>> >>>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1 >>>> interface (as discussed with Christoffer below). So it should generate the CPER >>>> before injecting the error. >>>> >>>> This is corresponds to (1) above apart from notifying UEFI (I am assuming you >>>> mean guest UEFI). At this time, the guest OS already knows where to pick up the >>>> CPER from through the HEST. Qemu has to create the CPER and populate its address >>>> at the address exported in the HEST. Guest UEFI should not be involved in this >>>> flow. Its job was to create the HEST at boot and that has been done by this >>>> stage. >>>> >>>> Qemu folk will be able to add but it looks like support for CPER generation will >>>> need to be added to Qemu. We need to resolve this. >>>> >>>> Do shout if I am missing anything above. >>> >>> After reading this email, the use case looks *very* similar to what >>> we've just done with VMGENID for QEMU 2.9. >>> >>> We have a facility between QEMU and the guest firmware, called "ACPI >>> linker/loader", with which QEMU instructs the firmware to >>> >>> - allocate and download blobs into guest RAM (AcpiNVS type memory) -- >>> ALLOCATE command, >>> >>> - relocate pointers in those blobs, to fields in other (or the same) >>> blobs -- ADD_POINTER command, >>> >>> - set ACPI table checksums -- ADD_CHECKSUM command, >>> >>> - and send GPAs of fields within such blobs back to QEMU -- >>> WRITE_POINTER command. >>> >>> This is how I imagine we can map the facility to the current use case >>> (note that this is the first time I read about HEST / GHES / CPER): Laszlo lists a Qemu GHES table generation solution, Mainly use the four commands: "ALLOCATE/ADD_POINTER/ADD_CHECKSUM/WRITE_POINTER" to communicate with BIOS so whether the four commands needs to be supported by the guest firware/UEFI. I found the "WRITE_POINTER" always failed. so I suspect guest UEFI/firmware not support the "WRITE_POINTER" command. please help me confirm it, thanks so much. From mboxrd@z Thu Jan 1 00:00:00 1970 From: gengdongjiu@huawei.com (gengdongjiu) Date: Fri, 21 Apr 2017 21:27:31 +0800 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> References: <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> <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> <20170329103658.GQ23682@e104320-lin> <2a427164-9b37-6711-3a56-906634ba7f12@redhat.com> <7c5c8ab7-8fcc-1c98-0bc1-cccb66c4c84d@huawei.com> <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> Message-ID: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi all/Laszlo, sorry, I have a question to consult with you. On 2017/4/7 2:55, Laszlo Ersek wrote: > On 04/06/17 14:35, gengdongjiu wrote: >> Dear, Laszlo >> Thanks for your detailed explanation. >> >> On 2017/3/29 19:58, Laszlo Ersek wrote: >>> (This ought to be one of the longest address lists I've ever seen :) >>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good >>> measure, I'm adding MST and Igor.) >>> >>> On 03/29/17 12:36, Achin Gupta wrote: >>>> Hi gengdongjiu, >>>> >>>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote: >>>>> >>>>> 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. >>>> >>>> Just being pedantic! I don't think we are talking about creating the APEI table >>>> dynamically here. The issue is: Once KVM has received an error that is destined >>>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the error >>>> into the guest OS, a CPER (Common Platform Error Record) has to be generated >>>> corresponding to the error source (GHES corresponding to memory subsystem, >>>> processor etc) to allow the guest OS to do anything meaningful with the >>>> error. So who should create the CPER is the question. >>>> >>>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error arrives >>>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is >>>> responsible for creating the CPER. ARM is experimenting with using a Standalone >>>> MM EDK2 image in the secure world to do the CPER creation. This will avoid >>>> adding the same code in ARM TF in EL3 (better for security). The error will then >>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted >>>> Firmware. >>>> >>>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1 >>>> interface (as discussed with Christoffer below). So it should generate the CPER >>>> before injecting the error. >>>> >>>> This is corresponds to (1) above apart from notifying UEFI (I am assuming you >>>> mean guest UEFI). At this time, the guest OS already knows where to pick up the >>>> CPER from through the HEST. Qemu has to create the CPER and populate its address >>>> at the address exported in the HEST. Guest UEFI should not be involved in this >>>> flow. Its job was to create the HEST at boot and that has been done by this >>>> stage. >>>> >>>> Qemu folk will be able to add but it looks like support for CPER generation will >>>> need to be added to Qemu. We need to resolve this. >>>> >>>> Do shout if I am missing anything above. >>> >>> After reading this email, the use case looks *very* similar to what >>> we've just done with VMGENID for QEMU 2.9. >>> >>> We have a facility between QEMU and the guest firmware, called "ACPI >>> linker/loader", with which QEMU instructs the firmware to >>> >>> - allocate and download blobs into guest RAM (AcpiNVS type memory) -- >>> ALLOCATE command, >>> >>> - relocate pointers in those blobs, to fields in other (or the same) >>> blobs -- ADD_POINTER command, >>> >>> - set ACPI table checksums -- ADD_CHECKSUM command, >>> >>> - and send GPAs of fields within such blobs back to QEMU -- >>> WRITE_POINTER command. >>> >>> This is how I imagine we can map the facility to the current use case >>> (note that this is the first time I read about HEST / GHES / CPER): Laszlo lists a Qemu GHES table generation solution, Mainly use the four commands: "ALLOCATE/ADD_POINTER/ADD_CHECKSUM/WRITE_POINTER" to communicate with BIOS so whether the four commands needs to be supported by the guest firware/UEFI. I found the "WRITE_POINTER" always failed. so I suspect guest UEFI/firmware not support the "WRITE_POINTER" command. please help me confirm it, thanks so much.