From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755926AbdC2NhR (ORCPT ); Wed, 29 Mar 2017 09:37:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51210 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755478AbdC2NhP (ORCPT ); Wed, 29 Mar 2017 09:37:15 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5DB397E9CD Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5DB397E9CD Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS To: "Michael S. Tsirkin" References: <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> <20170329154539-mutt-send-email-mst@kernel.org> Cc: Achin Gupta , gengdongjiu , 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, Igor Mammedov From: Laszlo Ersek Message-ID: <756e3032-e619-a70d-3e29-d2797e52fecf@redhat.com> Date: Wed, 29 Mar 2017 15:36:59 +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: <20170329154539-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 29 Mar 2017 13:37:14 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/29/17 14:51, Michael S. Tsirkin wrote: > On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote: >> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come >> through a signalfd -- QEMU can format the CPER right into guest memory, >> and then inject whatever interrupt (or assert whatever GPIO line) is >> necessary for notifying the guest. > > I think I see a race condition potential - what if guest accesses > CPER in guest memory while it's being written? I'm not entirely sure about the data flow here (these parts of the ACPI spec are particularly hard to read...), but I thought the OS wouldn't look until it got a notification. Or, are you concerned about the next CPER write by QEMU, while the OS is reading the last one (and maybe the CPER area could wrap around?) > > We can probably use another level of indirection to fix this: > > allocate twice the space, add a pointer to where the valid > table is located and update that after writing CPER completely. > The pointer can be written atomically but also needs to > be read atomically, so I suspect it should be a single byte > as we don't know how are OSPMs implementing this. > A-B-A problem? (Is that usually solved with a cookie or a wider generation counter? But that would again require wider atomics.) I do wonder though how this is handled on physical hardware. Assuming the hardware error traps to the firmware first (which, on phys hw, is responsible for depositing the CPER), in that scenario the phys firmware would face the same issue (i.e., asynchronously interrupting the OS, which could be reading the previously stored CPER). Thanks, Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Wed, 29 Mar 2017 15:36:59 +0200 Message-ID: <756e3032-e619-a70d-3e29-d2797e52fecf@redhat.com> References: <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> <20170329154539-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, catalin.marinas@arm.com, Achin Gupta , will.deacon@arm.com, qemu-devel@nongnu.org, wuquanming@huawei.com, kvmarm@lists.cs.columbia.edu, Christoffer Dall , gengdongjiu , Leif.Lindholm@linaro.com, huangshaoyu@huawei.com, Marc Zyngier , andre.przywara@arm.com, edk2-devel@lists.01.org, wangxiongfeng2@huawei.com, nd@arm.com, linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org, linux-kernel@vger.kernel.org, Igor Mammedov To: "Michael S. Tsirkin" Return-path: In-Reply-To: <20170329154539-mutt-send-email-mst@kernel.org> 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 On 03/29/17 14:51, Michael S. Tsirkin wrote: > On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote: >> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come >> through a signalfd -- QEMU can format the CPER right into guest memory, >> and then inject whatever interrupt (or assert whatever GPIO line) is >> necessary for notifying the guest. > > I think I see a race condition potential - what if guest accesses > CPER in guest memory while it's being written? I'm not entirely sure about the data flow here (these parts of the ACPI spec are particularly hard to read...), but I thought the OS wouldn't look until it got a notification. Or, are you concerned about the next CPER write by QEMU, while the OS is reading the last one (and maybe the CPER area could wrap around?) > > We can probably use another level of indirection to fix this: > > allocate twice the space, add a pointer to where the valid > table is located and update that after writing CPER completely. > The pointer can be written atomically but also needs to > be read atomically, so I suspect it should be a single byte > as we don't know how are OSPMs implementing this. > A-B-A problem? (Is that usually solved with a cookie or a wider generation counter? But that would again require wider atomics.) I do wonder though how this is handled on physical hardware. Assuming the hardware error traps to the firmware first (which, on phys hw, is responsible for depositing the CPER), in that scenario the phys firmware would face the same issue (i.e., asynchronously interrupting the OS, which could be reading the previously stored CPER). Thanks, Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ctDmq-0000gA-9B for qemu-devel@nongnu.org; Wed, 29 Mar 2017 09:37:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ctDmm-0002EI-9z for qemu-devel@nongnu.org; Wed, 29 Mar 2017 09:37:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45826) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ctDmm-0002Dy-0y for qemu-devel@nongnu.org; Wed, 29 Mar 2017 09:37:16 -0400 References: <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> <20170329154539-mutt-send-email-mst@kernel.org> From: Laszlo Ersek Message-ID: <756e3032-e619-a70d-3e29-d2797e52fecf@redhat.com> Date: Wed, 29 Mar 2017 15:36:59 +0200 MIME-Version: 1.0 In-Reply-To: <20170329154539-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: Achin Gupta , gengdongjiu , 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, Igor Mammedov On 03/29/17 14:51, Michael S. Tsirkin wrote: > On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote: >> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come >> through a signalfd -- QEMU can format the CPER right into guest memory, >> and then inject whatever interrupt (or assert whatever GPIO line) is >> necessary for notifying the guest. > > I think I see a race condition potential - what if guest accesses > CPER in guest memory while it's being written? I'm not entirely sure about the data flow here (these parts of the ACPI spec are particularly hard to read...), but I thought the OS wouldn't look until it got a notification. Or, are you concerned about the next CPER write by QEMU, while the OS is reading the last one (and maybe the CPER area could wrap around?) > > We can probably use another level of indirection to fix this: > > allocate twice the space, add a pointer to where the valid > table is located and update that after writing CPER completely. > The pointer can be written atomically but also needs to > be read atomically, so I suspect it should be a single byte > as we don't know how are OSPMs implementing this. > A-B-A problem? (Is that usually solved with a cookie or a wider generation counter? But that would again require wider atomics.) I do wonder though how this is handled on physical hardware. Assuming the hardware error traps to the firmware first (which, on phys hw, is responsible for depositing the CPER), in that scenario the phys firmware would face the same issue (i.e., asynchronously interrupting the OS, which could be reading the previously stored CPER). Thanks, Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 From: lersek@redhat.com (Laszlo Ersek) Date: Wed, 29 Mar 2017 15:36:59 +0200 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <20170329154539-mutt-send-email-mst@kernel.org> References: <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> <20170329154539-mutt-send-email-mst@kernel.org> Message-ID: <756e3032-e619-a70d-3e29-d2797e52fecf@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/29/17 14:51, Michael S. Tsirkin wrote: > On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote: >> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come >> through a signalfd -- QEMU can format the CPER right into guest memory, >> and then inject whatever interrupt (or assert whatever GPIO line) is >> necessary for notifying the guest. > > I think I see a race condition potential - what if guest accesses > CPER in guest memory while it's being written? I'm not entirely sure about the data flow here (these parts of the ACPI spec are particularly hard to read...), but I thought the OS wouldn't look until it got a notification. Or, are you concerned about the next CPER write by QEMU, while the OS is reading the last one (and maybe the CPER area could wrap around?) > > We can probably use another level of indirection to fix this: > > allocate twice the space, add a pointer to where the valid > table is located and update that after writing CPER completely. > The pointer can be written atomically but also needs to > be read atomically, so I suspect it should be a single byte > as we don't know how are OSPMs implementing this. > A-B-A problem? (Is that usually solved with a cookie or a wider generation counter? But that would again require wider atomics.) I do wonder though how this is handled on physical hardware. Assuming the hardware error traps to the firmware first (which, on phys hw, is responsible for depositing the CPER), in that scenario the phys firmware would face the same issue (i.e., asynchronously interrupting the OS, which could be reading the previously stored CPER). Thanks, Laszlo