From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755961AbdC2KhN (ORCPT ); Wed, 29 Mar 2017 06:37:13 -0400 Received: from mail-ve1eur01on0083.outbound.protection.outlook.com ([104.47.1.83]:29184 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755527AbdC2KhJ (ORCPT ); Wed, 29 Mar 2017 06:37:09 -0400 Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=arm.com; Date: Wed, 29 Mar 2017 11:36:59 +0100 From: Achin Gupta To: gengdongjiu CC: , , , , , James Morse , Christoffer Dall , , Marc Zyngier , , , , , , , , , , , , , , , , , Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Message-ID: <20170329103658.GQ23682@e104320-lin> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: AM5PR04CA0009.eurprd04.prod.outlook.com (2603:10a6:206:1::22) To DB5PR08MB1080.eurprd08.prod.outlook.com (2a01:111:e400:c585::15) X-MS-Office365-Filtering-Correlation-Id: 47157378-0cc4-4d23-42ad-08d4768f7777 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:DB5PR08MB1080; X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB1080;3:HD3uCjQPX6uZg+twOGu/v8hEutq7K+BzG9N32aWBzqm+qlG67Xme2QGmn6YpK1tKfJBvv8lW7el39SxCQYJHG5/ahTxdQWAfQdJ8qVuZwRSAL6BC9ZweEuSd0adUxvS1WKHJ7TkENoVUaHIJCQTfZJBQThs1HkBOuftjWieik7kLX42Ifa06/EBew+/YkC0JszVTrVH+Ir/qLIMXINNN40ev0eWooI2JYIndovWZrp3XMah6KXrS66qt8pQABjCCHHpklm3g7zvoR/DP7VQ157zIJC9lN/j8pnaw327PAFPWZGqrYb2XO2Q5R2IonNpEcwC2ZBxRTkbLWovDWfuMVTrNqNCn7my9Pe+CNOmlsxk=;25:wDGf3MNiXB9c+0A3G2fERu2iGf5bByv8vykiFTCFXje0+NuDhus9fDaydhkK2uBPE9XnNEyTn8BZg6xsc6XeQKo51ler08xOAj4ZumJXk/IkFYqMRtqbVi4w7Egl7P0U9+M+PHd0VRWJ+mfS8tssbnfeGG5jZ+QCuL8Uyvu+7lM/t03xyvdaJr5ePTf26eS0PGNoJhctmbqXtlC7AnVJ4RnZ04DOtNZm4a6bw/9Cyyo72kx4QcGyQr9OpymupeNJOEV9r+FEW5ljeQyzLtZvISv6YgCKo/cXDjTdYbSQlZG+CgP4/bHHWUYLGXDqi4Gf5BF5/7vQTfLcxSrqWUnizwgV3MLQi7MKLLDsX0xhUnoOHwgQJ27CVpkv2EpG0bIAV6AK0rVhzFlTqNCkuiimFDMRbHp0rqfsb/w4oOQ3btvQC/8V4l3rrX6Phq6K8WLYr6haP2K5EvtefNz2y6lbDQ== X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB1080;31:7wTN9hilGtcu66N4xrN51817YOQYKBFYNnSVrXhPkv2Vn06v2HC5I7l9n+tDYSy8IZvEaTzlJ3l59sgHHREtlQ+Kv6UcaLOuB+dgwESr1ljjTpNviHLbbFZ52rgMJwoS7bJCoX+AtrzxkO5HtqqpA6q5rcxz5Mq5f1j8eOybJ22skqf6OLjPRJqMtK05Tl/wrAdaJzCOcEGw1UzvkjdZUL8iWGyYOr5Sq+DKB7NkR5APExlbuoxcVvK6YKLfk2AG;20:DNbBtf1n2PKmLGX7VhR2p4WdawkicO7ZmL+Fb918gvgfCw7mOvw6kTBB0VQbEROCQUcKsXOTpSFVswD5aeD0pit1yybOfzHR27lLomJTrEljcZO8dlw/sTcYEU4aJmk2bREJRGUzRGt2+GNwAGULvWYwSklsiMf3NC3hzLm87kA= NoDisclaimer: True X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(192374486261705)(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040449)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423074)(201702281528074)(201703061421074)(201703061406074)(20161123558025)(20161123564025)(20161123562025)(6072148);SRVR:DB5PR08MB1080;BCL:0;PCL:0;RULEID:;SRVR:DB5PR08MB1080; X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB1080;4:bU1gOvWnNWWN0mv1ZlHS1pD00f4kFtexqFRTL4jqNpnWsiug/1EowqbZvlyRpHgzPr+mERuWpmsiJht3MQvhXaH3l+Fk1h0e/w+clKEuVuAgd/V/5mWGE9zCepfAc20EiMRoA4CpyO9SMVCPFFF7I//U2mMgca62zylAWEXtGEuLR4c0kv9VGwtuMtRFuiRzEUb2zBn7k86XcSW/cyxEc6AixbwtqJPOMg5tqN3kPehnlaZ5O1/HMGxx0Dm+CgUdD+TBe1itWmAKKpuh0yM9W+MWZ3A//c8wHlaKYWDm3Dsq5mElyfx7KvfPIknpq00qKSer1JCFKNPDTaNLqWuqERHuSETtRnv7r0CcmkA/zseIn/CO78YEbZbEGgq1MhmwAwm5BcPz/9he8MwqjmqmIUyTgRV8d+mkpyUF95zwUB06DLDFTjuxld16CYIeNGkqMLluQO1q7EjZ8rueg0sqMrcnjGqeEeBKp54neUfGDf996qRJS0DWm9JxI4OLOSQsIRd/PO1aSrtm4QfL4RLksY8moWeZwtrmCTMMW0vkeUPX1gb8r20d8M2dMqGbIa8nM6KTUsm3Qs30ALQoVhfzObFgdseYRCcEuk7IB0DUSh2SL08jSRoH4TLc3GNW2lq4BF66a8cqHUFCTjEcebVzwRDIr0H5DYB5yigtDq/FQrLMGHS2u3Hpvtr+ZO6/aazD1oQDveayDOBWQBstPCJ3im/oTkm9BNL6atbbUgC8NBjAF9dYosGiMTwZ7t4FuT14eIypKrp289Q3zUtdWs4p673eeAw3S3CFJ+j5e20TyM+78h0k4+ejVWtHIlYXP12uwWzL/itSwNBL2VWVyUeOXKFiXBfAM/TLWUdls+3Zl73rVuZexs+CcKtQOMa/dxOI X-Forefront-PRVS: 0261CCEEDF X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(39400400002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(24454002)(23676002)(5660300001)(50466002)(66066001)(93886004)(7416002)(47776003)(33656002)(55016002)(9686003)(33716001)(189998001)(38730400002)(53936002)(6496005)(53546009)(86362001)(110136004)(4001350100001)(81166006)(2950100002)(83506001)(25786009)(76176999)(3846002)(1076002)(50986999)(8676002)(305945005)(6116002)(229853002)(42186005)(6246003)(6916009)(2906002)(6666003)(7736002)(54356999)(2870700001)(4326008)(18370500001)(107986001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB5PR08MB1080;H:e104320-lin;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA4TUIxMDgwOzIzOnZlTHE0VmhsWTNJenZyV0ZJVG1oTHljbENk?= =?utf-8?B?K2Y1USszdHZtL1FZaGd1ZFR2eW8yMVJGNjZ4V0RXK0NvaFBHWlh6aStBbm83?= =?utf-8?B?L1NXNGluZGc0L0lDSXMrNFR6QmprREVZdGd1NjAwSHcwdVVmeXZyaHZzYjNT?= =?utf-8?B?cGpNUTZUWUFrZjg5cmtzcUtIVjdBaXlQYUJaQkFKKzl4MEFtN0xIMjltTmlK?= =?utf-8?B?NVZDeEFZT2I4SHFkR2QyTjFzTXNxUkhvMHpvcFgySFBzQWNmckFnM29QQTZO?= =?utf-8?B?R1ZGamlEellOWVJRVHI3c0JyckJuYUVKZDE5cFpEMmkvYU9QTTZzSW43KzhZ?= =?utf-8?B?Nk5XZkNwNUhranBTcE9oOTgweWRNSTZIbzlvaTZrVkZMSFZIMUVHQ1dIVEVa?= =?utf-8?B?Q0JnZEQyODk1L0pKVmtmMVluQ3B5cGNoSUFNdHFyTGxkaFcweGpKb3ByY1ZK?= =?utf-8?B?a3VXeEorWUo0d3lGNTl5bzFBZkpQeDJFRXphdVpJZkJXb0ZnaGQ3Wnk0VkRE?= =?utf-8?B?QUQ2Q3pKcGhwM0xwVU52Qmc5WWxDZjNKUVoxUm1uV0QreG50ZXFScUVlak15?= =?utf-8?B?ZWJpWWJUL1IzZ0dEVmdZYVlxNVM5RUpCMkhkcU1HV3ovOXFieEpIa0NYUGIw?= =?utf-8?B?ZWN3S1RJMFJmU0d2bEp3NTdDaDNieUFTODR1ancwcDNZZm5LYjRVenEzQVVB?= =?utf-8?B?eU96Y05DUk9Ba2g5b3drS2ZpbDZQdW1Xc0lZYk9OcUM3VnJxNzY5aDdRSHVJ?= =?utf-8?B?RVR5OExYS0NZVXE3S252cU5DcUx0bVZ6MzE4NWdOaTV5alE2QkU4Qm5uT2pP?= =?utf-8?B?UmlKdE1MTFZ3aWFaYkRmbTdlbkdVZmFEWm9MSTdPMUFkSVFEdlU5ZkNTOWRX?= =?utf-8?B?SVRNdStsTnVvNkNlamQ0aWxLalF2RU1NOWxjOFBGZUdKdndhd3NuUXV0Z1My?= =?utf-8?B?L0FDRnRPRmFuaWRIS0hSbXBLRVN2TmV2Q3ZkNVpQOVRmcWZndGtEanBmSHhU?= =?utf-8?B?UGlNVnEyaWVuUXQ1NThEZmhRVysxOHpyL09sUjdqSnlKbVpJQnhUT2w0bmRx?= =?utf-8?B?emlCZjJCUkQ4V05UenRhenhCRkJ6MFNjTjdqNnlpdmpJMlo5SENtU1B1OUg2?= =?utf-8?B?cVdjTUNBQWxUckZKMFZUMTVLZUdvVkNHMlFkWSsvbWliNkpCOWpkdVRMTzNG?= =?utf-8?B?ZkVLT2dDa3h6eUIwUEpNd1dPZE5YTnpvZGlRY0ZVU3BxU2RWN0xKZm1lNWtx?= =?utf-8?B?aE1STWNiQjRlLzBDRk93a2YzK3VhcTdzOE1IRHF2Ylp0d252cm9HYjRTME9a?= =?utf-8?B?eXhmb1R2bnNvZ3lobXRuc1Z6dXVUTFlVazVIUWQwQXZhSFRKMmE3TDFQT3dR?= =?utf-8?B?RHJoOTF2RDYvRDZsQVpWQnN4VGZhUXBET0NzRkVNeUVsWGFGOVVnZDNXNysy?= =?utf-8?B?SE85MW0zc1l3MFhMdElGa214TDhIczlKL2xHdTZxVGpnUm5xRWtzem5qR04v?= =?utf-8?B?NEx3bHhtWTA3eVhjKzBUZXJPbkl5M3RwdGRiVzRqYVkvTGY4UFJQUEI2Uzcw?= =?utf-8?B?b1A4WXZwaithYlpPMy8yRU1JNnRmZDhHZnM1VWYrbHhxYWZ2OEc5ZDNmUmE2?= =?utf-8?B?K0hPbDhsOUh5US8zUFZJbzkrRWQzZUpCdjB2VER1cmFHUHFGenQyK3lYWTBE?= =?utf-8?Q?xqrEJnJdh5R0WUGUsl7UXfi6qU+FtmXc2lnpXMw?= X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB1080;6:pXjYtGX8xaD9y6+KFFDxwlbJi+DqEaJCauXKLoFrsYGdj+69flCTkNvFkb/PQhlelnFRR8AcTZf7u39ycyw6GNSJfVxfZMToBkCeBaamlc1eeIUbY23y5pcPi1mvYQVvar04IH/oT4gVWwCu/R588GnfscMMiJoAS6nZ7cc6ZfpSXAqBx6hJEknNsGYYCx2Jto3VHtCero2SSQ3LuO8xw/C6BYcdJ2sdxj+Sm3zGwzKgrpf3NTYy3fMj93KYt5dJxBDum55LvTP1aUj9gCkRavRMaWxQ2OrWJ2W2WSE/L0ibI6Jzaj/9ZH0ZslEk+a6cbX9DL2qW4McK35SwoXlJQTsQ4qC0WLeMCcg0sSOwwqIxy23kXt2wQNGST19udii9BATaO4U/1xxq6Lqpa30Ri4AZDR5IhLX4HuB4umbTFWQ=;5:oNYygag/EXu9T6pYmPnZb8A+PPP1yDGVRrpySxdjVHhJBmqDgWchig8zOwU2G9GVUIKJxCK94qO7a0X4d31hFAjfhr2/djDtX+L+QlbLUqqSJEsOF9tuBsrNQs8WXsD9F9M3oaxnt5z8gNFIjuFiig==;24:O05UfraOhxW+rs7h5zcONxNnia7MJq2uh+ym6knvp7n87ikQGWnCaLwK1D0gojhUTtr8yu1EWeuaA2+fw6N6QkFNaUIqCPSUJkqY2BYdOYs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DB5PR08MB1080;7:Q4y6LL4V7rOJNWoY+MAbrHIIaOowoOmWCQv0qC/d1ebh3Uwggodi8linRugsp9GvnlKxiDFDH/vMsFwgD2AKR3mz4WpmPm30wHDe4FWd/iYZ/D/g/A5Umf0viZ0zhc95Re7Ryz5p0dzZagHgR8DqO2Y4D8QJyOqK8d6fWu3OXjxhfkm2Ti3jy/B5WdC5tmr7OKt/YcFASRXjeniuZ9X76eEXbwP+bj5Mg02297mvySNh0HSfujVf7ujd1zFDWvMxRFjom0BHIB+fCbN39Am6OdG7fdleBQZ7Rx6tlhhuWCOO7uzqKWo7/4hbC+iKBxGlCVYlSyqwWI3d9d4Wqa+CWg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2017 10:36:30.9847 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB1080 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. cheers, Achin > > > 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: Achin Gupta Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Wed, 29 Mar 2017 11:36:59 +0100 Message-ID: <20170329103658.GQ23682@e104320-lin> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: kvm@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, qemu-devel@nongnu.org, wuquanming@huawei.com, wangxiongfeng2@huawei.com, Christoffer Dall , kvmarm@lists.cs.columbia.edu, Leif.Lindholm@linaro.com, huangshaoyu@huawei.com, lersek@redhat.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 To: gengdongjiu Return-path: Content-Disposition: inline In-Reply-To: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.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 SGkgZ2VuZ2RvbmdqaXUsCgpPbiBXZWQsIE1hciAyOSwgMjAxNyBhdCAwNTozNjozN1BNICswODAw LCBnZW5nZG9uZ2ppdSB3cm90ZToKPgo+IEhpIExhc3psby9CaWVzaGV1dmVsL1FlbXUgZGV2ZWxv cGVyLAo+Cj4gICAgTm93IEkgZW5jb3VudGVyIGEgaXNzdWUgYW5kIHdhbnQgdG8gY29uc3VsdCB3 aXRoIHlvdSBpbiBBUk02NCBwbGF0Zm9ybe+8jCBhcyBkZXNjcmliZWQgYmVsb3c6Cj4KPiAgICB3 aGVuIGd1ZXN0IE9TIGhhcHBlbiBzeW5jaHJvbm91cyBvciBhc3luY2hyb25vdXMgYWJvcnQsIGt2 bSBuZWVkcyB0byBzZW5kIHRoZSBlcnJvciBhZGRyZXNzIHRvIFFlbXUgb3IgVUVGSSB0aHJvdWdo IHNpZ2J1cyB0byBkeW5hbWljYWxseSBnZW5lcmF0ZSBBUEVJIHRhYmxlLiBmcm9tIG15IGludmVz dGlnYXRpb24sIHRoZXJlIGFyZSB0d28gd2F5czoKPgo+ICAgICgxKSBRZW11IGdldCB0aGUgZXJy b3IgYWRkcmVzcywgYW5kIGdlbmVyYXRlIHRoZSBBUEVJIHRhYmxlLCB0aGVuIG5vdGlmeSBVRUZJ IHRvIGtub3cgdGhpcyBnZW5lcmF0aW9uLCB0aGVuIGluamVjdCBhYm9ydCBlcnJvciB0byBndWVz dCBPUywgZ3Vlc3QgT1MgcmVhZCB0aGUgQVBFSSB0YWJsZS4KPiAgICAoMikgUWVtdSBnZXQgdGhl IGVycm9yIGFkZHJlc3MsIGFuZCBsZXQgVUVGSSB0byBnZW5lcmF0ZSB0aGUgQVBFSSB0YWJsZSwg dGhlbiBpbmplY3QgYWJvcnQgZXJyb3IgdG8gZ3Vlc3QgT1MsIGd1ZXN0IE9TIHJlYWQgdGhlIEFQ RUkgdGFibGUuCgpKdXN0IGJlaW5nIHBlZGFudGljISBJIGRvbid0IHRoaW5rIHdlIGFyZSB0YWxr aW5nIGFib3V0IGNyZWF0aW5nIHRoZSBBUEVJIHRhYmxlCmR5bmFtaWNhbGx5IGhlcmUuIFRoZSBp c3N1ZSBpczogT25jZSBLVk0gaGFzIHJlY2VpdmVkIGFuIGVycm9yIHRoYXQgaXMgZGVzdGluZWQK Zm9yIGEgZ3Vlc3QgaXQgd2lsbCByYWlzZSBhIFNJR0JVUyB0byBRZW11LiBOb3cgYmVmb3JlIFFl bXUgY2FuIGluamVjdCB0aGUgZXJyb3IKaW50byB0aGUgZ3Vlc3QgT1MsIGEgQ1BFUiAoQ29tbW9u IFBsYXRmb3JtIEVycm9yIFJlY29yZCkgaGFzIHRvIGJlIGdlbmVyYXRlZApjb3JyZXNwb25kaW5n IHRvIHRoZSBlcnJvciBzb3VyY2UgKEdIRVMgY29ycmVzcG9uZGluZyB0byBtZW1vcnkgc3Vic3lz dGVtLApwcm9jZXNzb3IgZXRjKSB0byBhbGxvdyB0aGUgZ3Vlc3QgT1MgdG8gZG8gYW55dGhpbmcg bWVhbmluZ2Z1bCB3aXRoIHRoZQplcnJvci4gU28gd2hvIHNob3VsZCBjcmVhdGUgdGhlIENQRVIg aXMgdGhlIHF1ZXN0aW9uLgoKQXQgdGhlIEVMMy9FTDIgaW50ZXJmYWNlIChTZWN1cmUgRmlybXdh cmUgYW5kIE9TL0h5cGVydmlzb3IpLCBhbiBlcnJvciBhcnJpdmVzCmF0IEVMMyBhbmQgc2VjdXJl IGZpcm13YXJlIChhdCBFTDMgb3IgYSBsb3dlciBzZWN1cmUgZXhjZXB0aW9uIGxldmVsKSBpcwpy ZXNwb25zaWJsZSBmb3IgY3JlYXRpbmcgdGhlIENQRVIuIEFSTSBpcyBleHBlcmltZW50aW5nIHdp dGggdXNpbmcgYSBTdGFuZGFsb25lCk1NIEVESzIgaW1hZ2UgaW4gdGhlIHNlY3VyZSB3b3JsZCB0 byBkbyB0aGUgQ1BFUiBjcmVhdGlvbi4gVGhpcyB3aWxsIGF2b2lkCmFkZGluZyB0aGUgc2FtZSBj b2RlIGluIEFSTSBURiBpbiBFTDMgKGJldHRlciBmb3Igc2VjdXJpdHkpLiBUaGUgZXJyb3Igd2ls bCB0aGVuCmJlIGluamVjdGVkIGludG8gdGhlIE9TL0h5cGVydmlzb3IgKHRocm91Z2ggU0VBL1NF SS9TREVJKSB0aHJvdWdoIEFSTSBUcnVzdGVkCkZpcm13YXJlLgoKUWVtdSBpcyBlc3NlbnRpYWxs eSBmdWxmaWxsaW5nIHRoZSByb2xlIG9mIHNlY3VyZSBmaXJtd2FyZSBhdCB0aGUgRUwyL0VMMQpp bnRlcmZhY2UgKGFzIGRpc2N1c3NlZCB3aXRoIENocmlzdG9mZmVyIGJlbG93KS4gU28gaXQgc2hv dWxkIGdlbmVyYXRlIHRoZSBDUEVSCmJlZm9yZSBpbmplY3RpbmcgdGhlIGVycm9yLgoKVGhpcyBp cyBjb3JyZXNwb25kcyB0byAoMSkgYWJvdmUgYXBhcnQgZnJvbSBub3RpZnlpbmcgVUVGSSAoSSBh bSBhc3N1bWluZyB5b3UKbWVhbiBndWVzdCBVRUZJKS4gQXQgdGhpcyB0aW1lLCB0aGUgZ3Vlc3Qg T1MgYWxyZWFkeSBrbm93cyB3aGVyZSB0byBwaWNrIHVwIHRoZQpDUEVSIGZyb20gdGhyb3VnaCB0 aGUgSEVTVC4gUWVtdSBoYXMgdG8gY3JlYXRlIHRoZSBDUEVSIGFuZCBwb3B1bGF0ZSBpdHMgYWRk cmVzcwphdCB0aGUgYWRkcmVzcyBleHBvcnRlZCBpbiB0aGUgSEVTVC4gR3Vlc3QgVUVGSSBzaG91 bGQgbm90IGJlIGludm9sdmVkIGluIHRoaXMKZmxvdy4gSXRzIGpvYiB3YXMgdG8gY3JlYXRlIHRo ZSBIRVNUIGF0IGJvb3QgYW5kIHRoYXQgaGFzIGJlZW4gZG9uZSBieSB0aGlzCnN0YWdlLgoKUWVt dSBmb2xrIHdpbGwgYmUgYWJsZSB0byBhZGQgYnV0IGl0IGxvb2tzIGxpa2Ugc3VwcG9ydCBmb3Ig Q1BFUiBnZW5lcmF0aW9uIHdpbGwKbmVlZCB0byBiZSBhZGRlZCB0byBRZW11LiBXZSBuZWVkIHRv IHJlc29sdmUgdGhpcy4KCkRvIHNob3V0IGlmIEkgYW0gbWlzc2luZyBhbnl0aGluZyBhYm92ZS4K CmNoZWVycywKQWNoaW4KCgo+Cj4KPiAgICBEbyB5b3UgdGhpbmsgd2hpY2ggbW9kdWxlcyBnZW5l cmF0ZXMgdGhlIEFQRUkgdGFibGUgaXMgYmV0dGVyPyBVRUZJIG9yIFFlbXU/Cj4KPgo+Cj4KPiBP biAyMDE3LzMvMjggMjE6NDAsIEphbWVzIE1vcnNlIHdyb3RlOgo+ID4gSGkgZ2VuZ2RvbmdqaXUs Cj4gPgo+ID4gT24gMjgvMDMvMTcgMTM6MTYsIGdlbmdkb25naml1IHdyb3RlOgo+ID4+IE9uIDIw MTcvMy8yOCAxOTo1NCwgQWNoaW4gR3VwdGEgd3JvdGU6Cj4gPj4+IE9uIFR1ZSwgTWFyIDI4LCAy MDE3IGF0IDAxOjIzOjI4UE0gKzAyMDAsIENocmlzdG9mZmVyIERhbGwgd3JvdGU6Cj4gPj4+PiBP biBUdWUsIE1hciAyOCwgMjAxNyBhdCAxMTo0ODowOEFNICswMTAwLCBKYW1lcyBNb3JzZSB3cm90 ZToKPiA+Pj4+PiBPbiB0aGUgaG9zdCwgcGFydCBvZiBVRUZJIGlzIGludm9sdmVkIHRvIGdlbmVy YXRlIHRoZSBDUEVSIHJlY29yZHMuCj4gPj4+Pj4gSW4gYSBndWVzdD8sIEkgZG9uJ3Qga25vdy4K PiA+Pj4+PiBRZW11IGNvdWxkIGdlbmVyYXRlIHRoZSByZWNvcmRzLCBvciBkcml2ZSBzb21lIG90 aGVyIGNvbXBvbmVudCB0byBkbyBpdC4KPiA+Pj4+Cj4gPj4+PiBJIHRoaW5rIEkgYW0gYmVnaW5u aW5nIHRvIHVuZGVyc3RhbmQgdGhpcyBhIGJpdC4gIFNpbmNlIHRoZSBndWV0IFVFRkkKPiA+Pj4+ IGluc3RhbmNlIGlzIHNwZWNpZmljYWxseSBidWlsdCBmb3IgdGhlIG1hY2hpbmUgaXQgcnVucyBv biwgUUVNVSdzIHZpcnQKPiA+Pj4+IG1hY2hpbmUgaW4gdGhpcyBjYXNlLCB0aGV5IGNvdWxkIHNp bXBseSBhZ3JlZSAoYnkgc29tZSBjb250cmFjdCkgdG8KPiA+Pj4+IHBsYWNlIHRoZSByZWNvcmRz IGF0IHNvbWUgc3BlY2lmaWMgbG9jYXRpb24gaW4gbWVtb3J5LCBhbmQgaWYgdGhlIGd1ZXN0Cj4g Pj4+PiBrZXJuZWwgYXNrcyBpdHMgZ3Vlc3QgVUVGSSBmb3IgdGhhdCBsb2NhdGlvbiwgdGhpbmdz IHNob3VsZCBqdXN0IHdvcmsgYnkKPiA+Pj4+IGhhdmluZyBsb2dpYyBpbiBRRU1VIHRvIHByb2Nl c3MgZXJyb3IgcmVwb3J0cyBhbmQgcG9wdWxhdGUgZ3Vlc3QgbWVtb3J5Lgo+ID4+Pj4KPiA+Pj4+ IElzIHRoaXMgaG93IG90aGVycyBzZWUgdGhlIHdvcmxkIHRvbz8KPiA+Pj4KPiA+Pj4gSSB0aGlu ayBzbyEKPiA+Pj4KPiA+Pj4gQUZBSVUsIHRoZSBtZW1vcnkgd2hlcmUgQ1BFUnMgd2lsbCByZXNp ZGUgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiBhIEdIRVMgZW50cnkgaW4KPiA+Pj4gdGhlIEhFU1Qu IElzIHRoaXMgbm90IHRoZSBjYXNlIHdpdGggYSBndWVzdCBrZXJuZWwgaS5lLiB0aGUgZ3Vlc3Qg VUVGSSBjcmVhdGVzIGEKPiA+Pj4gSEVTVCBmb3IgdGhlIGd1ZXN0IEtlcm5lbD8KPiA+Pj4KPiA+ Pj4gSWYgc28sIHRoZW4gdGhlIHF1ZXN0aW9uIGlzIGhvdyB0aGUgZ3Vlc3QgVUVGSSBmaW5kcyBv dXQgd2hlcmUgUUVNVSAoYWN0aW5nIGFzCj4gPj4+IEVMMyBmaXJtd2FyZSkgd2lsbCBwb3B1bGF0 ZSB0aGUgQ1BFUnMuIFRoaXMgY291bGQgZWl0aGVyIGJlIGEgY29udHJhY3QgYmV0d2Vlbgo+ID4+ PiB0aGUgdHdvIG9yIGEgZ3Vlc3QgRFhFIGRyaXZlciB1c2VzIHRoZSBNTV9DT01NVU5JQ0FURSBj YWxsIChzZWUgWzFdKSB0byBhc2sgUUVNVQo+ID4+PiB3aGVyZSB0aGUgbWVtb3J5IGlzLgo+ID4+ Cj4gPj4gd2hldGhlciBpbnZva2UgdGhlIGd1ZXN0IFVFRkkgd2lsbCBiZSBjb21wbGV4PyBub3Qg c2VlIHRoZSBhZHZhbnRhZ2UuIGl0IHNlZW1zIHg4NiBRZW11Cj4gPj4gZGlyZWN0bHkgZ2VuZXJh dGUgdGhlIEFDUEkgdGFibGUsIGJ1dCBJIGFtIG5vdCBzdXJlLCB3ZSBhcmUgY2hlY2tpbmcgdGhl IHFlbXUKPiA+IGxvZ2ljYWwuCj4gPj4gbGV0IFFlbXUgZ2VuZXJhdGUgQ1BFUiByZWNvcmQgbWF5 IGJlIGNsZWFyLgo+ID4KPiA+IEF0IGJvb3QgVUVGSSBpbiB0aGUgZ3Vlc3Qgd2lsbCBuZWVkIHRv IG1ha2Ugc3VyZSB0aGUgYXJlYXMgb2YgbWVtb3J5IHRoYXQgbWF5IGJlCj4gPiB1c2VkIGZvciBD UEVSIHJlY29yZHMgYXJlIHJlc2VydmVkLiBXaGV0aGVyIFVFRkkgb3IgUWVtdSBkZWNpZGVzIHdo ZXJlIHRoZXNlIGFyZQo+ID4gbmVlZHMgZGVjaWRpbmcsIChidXQgcHJvYmFibHkgbm90IGhlcmUp Li4uCj4gPgo+ID4gQXQgcnVudGltZSwgd2hlbiBhbiBlcnJvciBoYXMgb2NjdXJyZWQsIEkgYWdy ZWUgaXQgd291bGQgYmUgc2ltcGxlciAoZmV3ZXIKPiA+IGNvbXBvbmVudHMgaW52b2x2ZWQpIGlm IFFlbXUgZ2VuZXJhdGVzIHRoZSBDUEVSIHJlY29yZHMuIEJ1dCBpZiBVRUZJIG1hZGUgdGhlCj4g PiBtZW1vcnkgY2hvaWNlIGFib3ZlIHRoZXkgbmVlZCB0byBpbnRlcmFjdCBhbmQgaXQgZ2V0cyBj b21wbGljYXRlZCBhZ2Fpbi4gVGhlCj4gPiBDUEVSIHJlY29yZHMgYXJlIGRlZmluZWQgaW4gdGhl IFVFRkkgc3BlYywgc28gSSB3b3VsZCBleHBlY3QgVUVGSSB0byBjb250YWluCj4gPiBjb2RlIHRv IGdlbmVyYXRlL3BhcnNlIHRoZW0uCj4gPgo+ID4KPiA+IFRoYW5rcywKPiA+Cj4gPiBKYW1lcwo+ ID4KPiA+Cj4gPiAuCj4gPgo+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmt2bWFybSBtYWlsaW5nIGxpc3QKa3ZtYXJtQGxpc3RzLmNzLmNvbHVtYmlhLmVk dQpodHRwczovL2xpc3RzLmNzLmNvbHVtYmlhLmVkdS9tYWlsbWFuL2xpc3RpbmZvL2t2bWFybQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctCQA-0003tL-0Y for qemu-devel@nongnu.org; Wed, 29 Mar 2017 08:09:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctCQ4-00029W-Rh for qemu-devel@nongnu.org; Wed, 29 Mar 2017 08:09:49 -0400 Received: from mail-db5eur01on0053.outbound.protection.outlook.com ([104.47.2.53]:9188 helo=EUR01-DB5-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctCQ4-00029A-DI for qemu-devel@nongnu.org; Wed, 29 Mar 2017 08:09:44 -0400 Date: Wed, 29 Mar 2017 11:36:59 +0100 From: Achin Gupta Message-ID: <20170329103658.GQ23682@e104320-lin> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> 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 Cc: lersek@redhat.com, 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 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= =EF=BC=8C as described below: > > when guest OS happen synchronous or asynchronous abort, kvm needs to s= end the error address to Qemu or UEFI through sigbus to dynamically generat= e APEI table. from my investigation, there are two ways: > > (1) Qemu get the error address, and generate the APEI table, then noti= fy 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 tabl= e, 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 t= able dynamically here. The issue is: Once KVM has received an error that is dest= ined 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 generate= d 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 arri= ves 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 Standa= lone 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 Trust= ed 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 y= ou 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 ad= dress at the address exported in the HEST. Guest UEFI should not be involved in t= his 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. cheers, Achin > > > 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 d= o it. > >>>> > >>>> I think I am beginning to understand this a bit. Since the guet UEF= I > >>>> instance is specifically built for the machine it runs on, QEMU's vi= rt > >>>> machine in this case, they could simply agree (by some contract) to > >>>> place the records at some specific location in memory, and if the gu= est > >>>> kernel asks its guest UEFI for that location, things should just wor= k by > >>>> having logic in QEMU to process error reports and populate guest mem= ory. > >>>> > >>>> Is this how others see the world too? > >>> > >>> I think so! > >>> > >>> AFAIU, the memory where CPERs will reside should be specified in a GH= ES entry in > >>> the HEST. Is this not the case with a guest kernel i.e. the guest UEF= I 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 contrac= t 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 t= he 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 th= at 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 (fe= wer > > components involved) if Qemu generates the CPER records. But if UEFI ma= de 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 co= ntain > > code to generate/parse them. > > > > > > Thanks, > > > > James > > > > > > . > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: achin.gupta@arm.com (Achin Gupta) Date: Wed, 29 Mar 2017 11:36:59 +0100 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <5b7352f4-4965-3ed5-3879-db871797be47@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> Message-ID: <20170329103658.GQ23682@e104320-lin> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. cheers, Achin > > > 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 > > > > > > . > > >