From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1168329AbdDXL2X (ORCPT ); Mon, 24 Apr 2017 07:28:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10665 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1166545AbdDXL2M (ORCPT ); Mon, 24 Apr 2017 07:28:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DCF1646D0B8 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DCF1646D0B8 Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS To: gengdongjiu , 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> <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Cc: ard.biesheuvel@linaro.org, edk2-devel@ml01.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.com, nd@arm.com, Michael Tsirkin , Igor Mammedov From: Laszlo Ersek Message-ID: <2aa1180d-2d05-d898-e1f2-be56c342a170@redhat.com> Date: Mon, 24 Apr 2017 13:27:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 24 Apr 2017 11:28:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/17 15:27, gengdongjiu wrote: > 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. That's incorrect, both OVMF and ArmVirtQemu support the WRITE_POINTER command (see .) A number of OvmfPkg/ modules are included in ArmVirtPkg binaries as well. In QEMU, the WRITE_POINTER command is currently generated for the VMGENID device only. If you try to test VMGENID with qemu-system-aarch64 (for the purposes of WRITE_POINTER testing), that won't work, because the VMGENID device is not available for aarch64. (The Microsoft spec that describes the device lists Windows OS versions that are x86 only.) In other words, no QEMU code exists at the moment that would allow you to readily test WRITE_POINTER in aarch64 guests. However, the firmware-side code is not architecture specific, and WRITE_POINTER support is already being built into ArmVirtQemu. Thanks, Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Mon, 24 Apr 2017 13:27:51 +0200 Message-ID: <2aa1180d-2d05-d898-e1f2-be56c342a170@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> <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.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: gengdongjiu , Achin Gupta Return-path: In-Reply-To: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.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 T24gMDQvMjEvMTcgMTU6MjcsIGdlbmdkb25naml1IHdyb3RlOgo+IEhpIGFsbC9MYXN6bG8sCj4g Cj4gICBzb3JyeSwgSSBoYXZlIGEgcXVlc3Rpb24gdG8gY29uc3VsdCB3aXRoIHlvdS4KPiAKPiAK PiBPbiAyMDE3LzQvNyAyOjU1LCBMYXN6bG8gRXJzZWsgd3JvdGU6Cj4+IE9uIDA0LzA2LzE3IDE0 OjM1LCBnZW5nZG9uZ2ppdSB3cm90ZToKPj4+IERlYXIsIExhc3psbwo+Pj4gICAgVGhhbmtzIGZv ciB5b3VyIGRldGFpbGVkIGV4cGxhbmF0aW9uLgo+Pj4KPj4+IE9uIDIwMTcvMy8yOSAxOTo1OCwg TGFzemxvIEVyc2VrIHdyb3RlOgo+Pj4+IChUaGlzIG91Z2h0IHRvIGJlIG9uZSBvZiB0aGUgbG9u Z2VzdCBhZGRyZXNzIGxpc3RzIEkndmUgZXZlciBzZWVuIDopCj4+Pj4gVGhhbmtzIGZvciB0aGUg Q0MuIEknbSBnbGFkIFNoYW5ub24gaXMgYWxyZWFkeSBvbiB0aGUgQ0MgbGlzdC4gRm9yIGdvb2QK Pj4+PiBtZWFzdXJlLCBJJ20gYWRkaW5nIE1TVCBhbmQgSWdvci4pCj4+Pj4KPj4+PiBPbiAwMy8y OS8xNyAxMjozNiwgQWNoaW4gR3VwdGEgd3JvdGU6Cj4+Pj4+IEhpIGdlbmdkb25naml1LAo+Pj4+ Pgo+Pj4+PiBPbiBXZWQsIE1hciAyOSwgMjAxNyBhdCAwNTozNjozN1BNICswODAwLCBnZW5nZG9u Z2ppdSB3cm90ZToKPj4+Pj4+Cj4+Pj4+PiBIaSBMYXN6bG8vQmllc2hldXZlbC9RZW11IGRldmVs b3BlciwKPj4+Pj4+Cj4+Pj4+PiAgICBOb3cgSSBlbmNvdW50ZXIgYSBpc3N1ZSBhbmQgd2FudCB0 byBjb25zdWx0IHdpdGggeW91IGluIEFSTTY0IHBsYXRmb3Jt77yMIGFzIGRlc2NyaWJlZCBiZWxv dzoKPj4+Pj4+Cj4+Pj4+PiB3aGVuIGd1ZXN0IE9TIGhhcHBlbiBzeW5jaHJvbm91cyBvciBhc3lu Y2hyb25vdXMgYWJvcnQsIGt2bSBuZWVkcwo+Pj4+Pj4gdG8gc2VuZCB0aGUgZXJyb3IgYWRkcmVz cyB0byBRZW11IG9yIFVFRkkgdGhyb3VnaCBzaWdidXMgdG8KPj4+Pj4+IGR5bmFtaWNhbGx5IGdl bmVyYXRlIEFQRUkgdGFibGUuIGZyb20gbXkgaW52ZXN0aWdhdGlvbiwgdGhlcmUgYXJlCj4+Pj4+ PiB0d28gd2F5czoKPj4+Pj4+Cj4+Pj4+PiAoMSkgUWVtdSBnZXQgdGhlIGVycm9yIGFkZHJlc3Ms IGFuZCBnZW5lcmF0ZSB0aGUgQVBFSSB0YWJsZSwgdGhlbgo+Pj4+Pj4gbm90aWZ5IFVFRkkgdG8g a25vdyB0aGlzIGdlbmVyYXRpb24sIHRoZW4gaW5qZWN0IGFib3J0IGVycm9yIHRvCj4+Pj4+PiBn dWVzdCBPUywgZ3Vlc3QgT1MgcmVhZCB0aGUgQVBFSSB0YWJsZS4KPj4+Pj4+ICgyKSBRZW11IGdl dCB0aGUgZXJyb3IgYWRkcmVzcywgYW5kIGxldCBVRUZJIHRvIGdlbmVyYXRlIHRoZSBBUEVJCj4+ Pj4+PiB0YWJsZSwgdGhlbiBpbmplY3QgYWJvcnQgZXJyb3IgdG8gZ3Vlc3QgT1MsIGd1ZXN0IE9T IHJlYWQgdGhlIEFQRUkKPj4+Pj4+IHRhYmxlLgo+Pj4+Pgo+Pj4+PiBKdXN0IGJlaW5nIHBlZGFu dGljISBJIGRvbid0IHRoaW5rIHdlIGFyZSB0YWxraW5nIGFib3V0IGNyZWF0aW5nIHRoZSBBUEVJ IHRhYmxlCj4+Pj4+IGR5bmFtaWNhbGx5IGhlcmUuIFRoZSBpc3N1ZSBpczogT25jZSBLVk0gaGFz IHJlY2VpdmVkIGFuIGVycm9yIHRoYXQgaXMgZGVzdGluZWQKPj4+Pj4gZm9yIGEgZ3Vlc3QgaXQg d2lsbCByYWlzZSBhIFNJR0JVUyB0byBRZW11LiBOb3cgYmVmb3JlIFFlbXUgY2FuIGluamVjdCB0 aGUgZXJyb3IKPj4+Pj4gaW50byB0aGUgZ3Vlc3QgT1MsIGEgQ1BFUiAoQ29tbW9uIFBsYXRmb3Jt IEVycm9yIFJlY29yZCkgaGFzIHRvIGJlIGdlbmVyYXRlZAo+Pj4+PiBjb3JyZXNwb25kaW5nIHRv IHRoZSBlcnJvciBzb3VyY2UgKEdIRVMgY29ycmVzcG9uZGluZyB0byBtZW1vcnkgc3Vic3lzdGVt LAo+Pj4+PiBwcm9jZXNzb3IgZXRjKSB0byBhbGxvdyB0aGUgZ3Vlc3QgT1MgdG8gZG8gYW55dGhp bmcgbWVhbmluZ2Z1bCB3aXRoIHRoZQo+Pj4+PiBlcnJvci4gU28gd2hvIHNob3VsZCBjcmVhdGUg dGhlIENQRVIgaXMgdGhlIHF1ZXN0aW9uLgo+Pj4+Pgo+Pj4+PiBBdCB0aGUgRUwzL0VMMiBpbnRl cmZhY2UgKFNlY3VyZSBGaXJtd2FyZSBhbmQgT1MvSHlwZXJ2aXNvciksIGFuIGVycm9yIGFycml2 ZXMKPj4+Pj4gYXQgRUwzIGFuZCBzZWN1cmUgZmlybXdhcmUgKGF0IEVMMyBvciBhIGxvd2VyIHNl Y3VyZSBleGNlcHRpb24gbGV2ZWwpIGlzCj4+Pj4+IHJlc3BvbnNpYmxlIGZvciBjcmVhdGluZyB0 aGUgQ1BFUi4gQVJNIGlzIGV4cGVyaW1lbnRpbmcgd2l0aCB1c2luZyBhIFN0YW5kYWxvbmUKPj4+ Pj4gTU0gRURLMiBpbWFnZSBpbiB0aGUgc2VjdXJlIHdvcmxkIHRvIGRvIHRoZSBDUEVSIGNyZWF0 aW9uLiBUaGlzIHdpbGwgYXZvaWQKPj4+Pj4gYWRkaW5nIHRoZSBzYW1lIGNvZGUgaW4gQVJNIFRG IGluIEVMMyAoYmV0dGVyIGZvciBzZWN1cml0eSkuIFRoZSBlcnJvciB3aWxsIHRoZW4KPj4+Pj4g YmUgaW5qZWN0ZWQgaW50byB0aGUgT1MvSHlwZXJ2aXNvciAodGhyb3VnaCBTRUEvU0VJL1NERUkp IHRocm91Z2ggQVJNIFRydXN0ZWQKPj4+Pj4gRmlybXdhcmUuCj4+Pj4+Cj4+Pj4+IFFlbXUgaXMg ZXNzZW50aWFsbHkgZnVsZmlsbGluZyB0aGUgcm9sZSBvZiBzZWN1cmUgZmlybXdhcmUgYXQgdGhl IEVMMi9FTDEKPj4+Pj4gaW50ZXJmYWNlIChhcyBkaXNjdXNzZWQgd2l0aCBDaHJpc3RvZmZlciBi ZWxvdykuIFNvIGl0IHNob3VsZCBnZW5lcmF0ZSB0aGUgQ1BFUgo+Pj4+PiBiZWZvcmUgaW5qZWN0 aW5nIHRoZSBlcnJvci4KPj4+Pj4KPj4+Pj4gVGhpcyBpcyBjb3JyZXNwb25kcyB0byAoMSkgYWJv dmUgYXBhcnQgZnJvbSBub3RpZnlpbmcgVUVGSSAoSSBhbSBhc3N1bWluZyB5b3UKPj4+Pj4gbWVh biBndWVzdCBVRUZJKS4gQXQgdGhpcyB0aW1lLCB0aGUgZ3Vlc3QgT1MgYWxyZWFkeSBrbm93cyB3 aGVyZSB0byBwaWNrIHVwIHRoZQo+Pj4+PiBDUEVSIGZyb20gdGhyb3VnaCB0aGUgSEVTVC4gUWVt dSBoYXMgdG8gY3JlYXRlIHRoZSBDUEVSIGFuZCBwb3B1bGF0ZSBpdHMgYWRkcmVzcwo+Pj4+PiBh dCB0aGUgYWRkcmVzcyBleHBvcnRlZCBpbiB0aGUgSEVTVC4gR3Vlc3QgVUVGSSBzaG91bGQgbm90 IGJlIGludm9sdmVkIGluIHRoaXMKPj4+Pj4gZmxvdy4gSXRzIGpvYiB3YXMgdG8gY3JlYXRlIHRo ZSBIRVNUIGF0IGJvb3QgYW5kIHRoYXQgaGFzIGJlZW4gZG9uZSBieSB0aGlzCj4+Pj4+IHN0YWdl Lgo+Pj4+Pgo+Pj4+PiBRZW11IGZvbGsgd2lsbCBiZSBhYmxlIHRvIGFkZCBidXQgaXQgbG9va3Mg bGlrZSBzdXBwb3J0IGZvciBDUEVSIGdlbmVyYXRpb24gd2lsbAo+Pj4+PiBuZWVkIHRvIGJlIGFk ZGVkIHRvIFFlbXUuIFdlIG5lZWQgdG8gcmVzb2x2ZSB0aGlzLgo+Pj4+Pgo+Pj4+PiBEbyBzaG91 dCBpZiBJIGFtIG1pc3NpbmcgYW55dGhpbmcgYWJvdmUuCj4+Pj4KPj4+PiBBZnRlciByZWFkaW5n IHRoaXMgZW1haWwsIHRoZSB1c2UgY2FzZSBsb29rcyAqdmVyeSogc2ltaWxhciB0byB3aGF0Cj4+ Pj4gd2UndmUganVzdCBkb25lIHdpdGggVk1HRU5JRCBmb3IgUUVNVSAyLjkuCj4+Pj4KPj4+PiBX ZSBoYXZlIGEgZmFjaWxpdHkgYmV0d2VlbiBRRU1VIGFuZCB0aGUgZ3Vlc3QgZmlybXdhcmUsIGNh bGxlZCAiQUNQSQo+Pj4+IGxpbmtlci9sb2FkZXIiLCB3aXRoIHdoaWNoIFFFTVUgaW5zdHJ1Y3Rz IHRoZSBmaXJtd2FyZSB0bwo+Pj4+Cj4+Pj4gLSBhbGxvY2F0ZSBhbmQgZG93bmxvYWQgYmxvYnMg aW50byBndWVzdCBSQU0gKEFjcGlOVlMgdHlwZSBtZW1vcnkpIC0tCj4+Pj4gQUxMT0NBVEUgY29t bWFuZCwKPj4+Pgo+Pj4+IC0gcmVsb2NhdGUgcG9pbnRlcnMgaW4gdGhvc2UgYmxvYnMsIHRvIGZp ZWxkcyBpbiBvdGhlciAob3IgdGhlIHNhbWUpCj4+Pj4gYmxvYnMgLS0gQUREX1BPSU5URVIgY29t bWFuZCwKPj4+Pgo+Pj4+IC0gc2V0IEFDUEkgdGFibGUgY2hlY2tzdW1zIC0tIEFERF9DSEVDS1NV TSBjb21tYW5kLAo+Pj4+Cj4+Pj4gLSBhbmQgc2VuZCBHUEFzIG9mIGZpZWxkcyB3aXRoaW4gc3Vj aCBibG9icyBiYWNrIHRvIFFFTVUgLS0KPj4+PiBXUklURV9QT0lOVEVSIGNvbW1hbmQuCj4+Pj4K Pj4+PiBUaGlzIGlzIGhvdyBJIGltYWdpbmUgd2UgY2FuIG1hcCB0aGUgZmFjaWxpdHkgdG8gdGhl IGN1cnJlbnQgdXNlIGNhc2UKPj4+PiAobm90ZSB0aGF0IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUg SSByZWFkIGFib3V0IEhFU1QgLyBHSEVTIC8gQ1BFUik6Cj4gCj4gTGFzemxvIGxpc3RzIGEgUWVt dSBHSEVTIHRhYmxlIGdlbmVyYXRpb24gc29sdXRpb24sIE1haW5seSB1c2UgdGhlCj4gZm91ciBj b21tYW5kczogIkFMTE9DQVRFL0FERF9QT0lOVEVSL0FERF9DSEVDS1NVTS9XUklURV9QT0lOVEVS IiB0bwo+IGNvbW11bmljYXRlIHdpdGggQklPUyBzbyB3aGV0aGVyIHRoZSBmb3VyIGNvbW1hbmRz IG5lZWRzIHRvIGJlCj4gc3VwcG9ydGVkIGJ5IHRoZSBndWVzdCBmaXJ3YXJlL1VFRkkuICBJIGZv dW5kIHRoZSAgIldSSVRFX1BPSU5URVIiCj4gYWx3YXlzIGZhaWxlZC4gc28gSSBzdXNwZWN0IGd1 ZXN0IFVFRkkvZmlybXdhcmUgbm90IHN1cHBvcnQgdGhlCj4gIldSSVRFX1BPSU5URVIiIGNvbW1h bmQuIHBsZWFzZSBoZWxwIG1lIGNvbmZpcm0gaXQsIHRoYW5rcyBzbyBtdWNoLgoKVGhhdCdzIGlu Y29ycmVjdCwgYm90aCBPVk1GIGFuZCBBcm1WaXJ0UWVtdSBzdXBwb3J0IHRoZSBXUklURV9QT0lO VEVSCmNvbW1hbmQgKHNlZSA8aHR0cHM6Ly9idWd6aWxsYS50aWFub2NvcmUub3JnL3Nob3dfYnVn LmNnaT9pZD0zNTk+LikgQQpudW1iZXIgb2YgT3ZtZlBrZy8gbW9kdWxlcyBhcmUgaW5jbHVkZWQg aW4gQXJtVmlydFBrZyBiaW5hcmllcyBhcyB3ZWxsLgoKSW4gUUVNVSwgdGhlIFdSSVRFX1BPSU5U RVIgY29tbWFuZCBpcyBjdXJyZW50bHkgZ2VuZXJhdGVkIGZvciB0aGUKVk1HRU5JRCBkZXZpY2Ug b25seS4gSWYgeW91IHRyeSB0byB0ZXN0IFZNR0VOSUQgd2l0aCBxZW11LXN5c3RlbS1hYXJjaDY0 Cihmb3IgdGhlIHB1cnBvc2VzIG9mIFdSSVRFX1BPSU5URVIgdGVzdGluZyksIHRoYXQgd29uJ3Qg d29yaywgYmVjYXVzZQp0aGUgVk1HRU5JRCBkZXZpY2UgaXMgbm90IGF2YWlsYWJsZSBmb3IgYWFy Y2g2NC4gKFRoZSBNaWNyb3NvZnQgc3BlYwp0aGF0IGRlc2NyaWJlcyB0aGUgZGV2aWNlIGxpc3Rz IFdpbmRvd3MgT1MgdmVyc2lvbnMgdGhhdCBhcmUgeDg2IG9ubHkuKQoKSW4gb3RoZXIgd29yZHMs IG5vIFFFTVUgY29kZSBleGlzdHMgYXQgdGhlIG1vbWVudCB0aGF0IHdvdWxkIGFsbG93IHlvdQp0 byByZWFkaWx5IHRlc3QgV1JJVEVfUE9JTlRFUiBpbiBhYXJjaDY0IGd1ZXN0cy4gSG93ZXZlciwg dGhlCmZpcm13YXJlLXNpZGUgY29kZSBpcyBub3QgYXJjaGl0ZWN0dXJlIHNwZWNpZmljLCBhbmQg V1JJVEVfUE9JTlRFUgpzdXBwb3J0IGlzIGFscmVhZHkgYmVpbmcgYnVpbHQgaW50byBBcm1WaXJ0 UWVtdS4KClRoYW5rcywKTGFzemxvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmVkazItZGV2ZWwgbWFpbGluZyBsaXN0CmVkazItZGV2ZWxAbGlzdHMuMDEu b3JnCmh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGluZm8vZWRrMi1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2cAE-0000Li-TH for qemu-devel@nongnu.org; Mon, 24 Apr 2017 07:28:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2cA9-0001WI-S1 for qemu-devel@nongnu.org; Mon, 24 Apr 2017 07:28:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46918) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d2cA9-0001WC-IT for qemu-devel@nongnu.org; Mon, 24 Apr 2017 07:28:13 -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> <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> From: Laszlo Ersek Message-ID: <2aa1180d-2d05-d898-e1f2-be56c342a170@redhat.com> Date: Mon, 24 Apr 2017 13:27:51 +0200 MIME-Version: 1.0 In-Reply-To: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: gengdongjiu , 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 On 04/21/17 15:27, gengdongjiu wrote: > Hi all/Laszlo, >=20 > sorry, I have a question to consult with you. >=20 >=20 > 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 g= ood >>>> 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 p= latform=EF=BC=8C 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 th= e 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 inj= ect 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 sub= system, >>>>> 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 er= ror arrives >>>>> at EL3 and secure firmware (at EL3 or a lower secure exception leve= l) 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 wil= l avoid >>>>> adding the same code in ARM TF in EL3 (better for security). The er= ror will then >>>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through A= RM Trusted >>>>> Firmware. >>>>> >>>>> Qemu is essentially fulfilling the role of secure firmware at the E= L2/EL1 >>>>> interface (as discussed with Christoffer below). So it should gener= ate the CPER >>>>> before injecting the error. >>>>> >>>>> This is corresponds to (1) above apart from notifying UEFI (I am as= suming 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 populat= e its address >>>>> at the address exported in the HEST. Guest UEFI should not be invol= ved 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 ge= neration 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 cas= e >>>> (note that this is the first time I read about HEST / GHES / CPER): >=20 > 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. That's incorrect, both OVMF and ArmVirtQemu support the WRITE_POINTER command (see .) A number of OvmfPkg/ modules are included in ArmVirtPkg binaries as well. In QEMU, the WRITE_POINTER command is currently generated for the VMGENID device only. If you try to test VMGENID with qemu-system-aarch64 (for the purposes of WRITE_POINTER testing), that won't work, because the VMGENID device is not available for aarch64. (The Microsoft spec that describes the device lists Windows OS versions that are x86 only.) In other words, no QEMU code exists at the moment that would allow you to readily test WRITE_POINTER in aarch64 guests. However, the firmware-side code is not architecture specific, and WRITE_POINTER support is already being built into ArmVirtQemu. Thanks, Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 From: lersek@redhat.com (Laszlo Ersek) Date: Mon, 24 Apr 2017 13:27:51 +0200 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <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> <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com> Message-ID: <2aa1180d-2d05-d898-e1f2-be56c342a170@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/21/17 15:27, gengdongjiu wrote: > 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. That's incorrect, both OVMF and ArmVirtQemu support the WRITE_POINTER command (see .) A number of OvmfPkg/ modules are included in ArmVirtPkg binaries as well. In QEMU, the WRITE_POINTER command is currently generated for the VMGENID device only. If you try to test VMGENID with qemu-system-aarch64 (for the purposes of WRITE_POINTER testing), that won't work, because the VMGENID device is not available for aarch64. (The Microsoft spec that describes the device lists Windows OS versions that are x86 only.) In other words, no QEMU code exists at the moment that would allow you to readily test WRITE_POINTER in aarch64 guests. However, the firmware-side code is not architecture specific, and WRITE_POINTER support is already being built into ArmVirtQemu. Thanks, Laszlo