From mboxrd@z Thu Jan 1 00:00:00 1970 From: Auger Eric Subject: Re: [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation Date: Wed, 26 Apr 2017 16:47:09 +0200 Message-ID: References: <1492164934-988-1-git-send-email-eric.auger@redhat.com> <1492164934-988-3-git-send-email-eric.auger@redhat.com> <20170426084830.GB2098@work-vm> <4dc866a0-582c-af69-916f-eb435988b5ec@redhat.com> <20170426130020.GM4104@cbox> <20170426131421.GA50776@lvm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Christoffer Dall , "Dr. David Alan Gilbert" , "prasun.kapoor" , Andrew Jones , kvm-devel , Juan Quintela , Marc Zyngier , Andre Przywara , Vijaya Kumar K , "Kumar, Vijaya" , Paolo Bonzini , "kvmarm@lists.cs.columbia.edu" , arm-mail-list , eric.auger.pro@gmail.com To: Peter Maydell , Christoffer Dall Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57796 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S3001389AbdDZOrP (ORCPT ); Wed, 26 Apr 2017 10:47:15 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Hi Peter, Christoffer, On 26/04/2017 15:26, Peter Maydell wrote: > On 26 April 2017 at 14:14, Christoffer Dall wrote: >> On Wed, Apr 26, 2017 at 02:01:55PM +0100, Peter Maydell wrote: >>> On 26 April 2017 at 14:00, Christoffer Dall wrote: >>>> Alternatively we should mark a pending error notification to the guest >>>> in KVM, so that when the guest boots it gets something like an SError >>>> instead, given that presumably the guest wrote the weird value. Except >>>> of course if the problem is caused by QEMU fudging with the register >>>> value for the PENDBASER. >>> >>> If we have scope for complaining at the guest we should do it at >>> the point where the guest sets PENDBASER in the first place... >>> >> >> Is that what the hardware would have done? > > I think it's UNPREDICTABLE to enable the GIC with a bogus PENDBASER, > but I can't find the bit in the spec that actually says that. > I don't know what hardware actually does, but I imagine it will > only notice that it's been handed bogus memory at the point where > it tries to use it. > >> Also, userspace could restore a bogus value in the PENDBASER (even >> though the guest wrote something sane), so maybe we should just keep >> this as is and handle it nicely in QEMU? > > Yeah, I don't have a strong objection to doing it that way round. OK. I will only update the QEMU code then. For info, without talking about save/restore, the GICR_PENDBASER is sync'ed on LPI enable. if the vITS gets an error on kvm_read_guest, we currently abort the sync without reporting any error. GICR_PROPBASER is read on cmd execution (MAPI, INV, INVALL). No error is reported at the moment. My understanding is our implementation chose the 3d alternative of GICV3 arch spec (6.3.2), ie. "the data that generated the error or errors is treated as having a legal value", increment the read cursor and currently we don't report any system error to the guest. Thanks Eric > > thanks > -- PMM > From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@redhat.com (Auger Eric) Date: Wed, 26 Apr 2017 16:47:09 +0200 Subject: [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation In-Reply-To: References: <1492164934-988-1-git-send-email-eric.auger@redhat.com> <1492164934-988-3-git-send-email-eric.auger@redhat.com> <20170426084830.GB2098@work-vm> <4dc866a0-582c-af69-916f-eb435988b5ec@redhat.com> <20170426130020.GM4104@cbox> <20170426131421.GA50776@lvm> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Peter, Christoffer, On 26/04/2017 15:26, Peter Maydell wrote: > On 26 April 2017 at 14:14, Christoffer Dall wrote: >> On Wed, Apr 26, 2017 at 02:01:55PM +0100, Peter Maydell wrote: >>> On 26 April 2017 at 14:00, Christoffer Dall wrote: >>>> Alternatively we should mark a pending error notification to the guest >>>> in KVM, so that when the guest boots it gets something like an SError >>>> instead, given that presumably the guest wrote the weird value. Except >>>> of course if the problem is caused by QEMU fudging with the register >>>> value for the PENDBASER. >>> >>> If we have scope for complaining at the guest we should do it at >>> the point where the guest sets PENDBASER in the first place... >>> >> >> Is that what the hardware would have done? > > I think it's UNPREDICTABLE to enable the GIC with a bogus PENDBASER, > but I can't find the bit in the spec that actually says that. > I don't know what hardware actually does, but I imagine it will > only notice that it's been handed bogus memory at the point where > it tries to use it. > >> Also, userspace could restore a bogus value in the PENDBASER (even >> though the guest wrote something sane), so maybe we should just keep >> this as is and handle it nicely in QEMU? > > Yeah, I don't have a strong objection to doing it that way round. OK. I will only update the QEMU code then. For info, without talking about save/restore, the GICR_PENDBASER is sync'ed on LPI enable. if the vITS gets an error on kvm_read_guest, we currently abort the sync without reporting any error. GICR_PROPBASER is read on cmd execution (MAPI, INV, INVALL). No error is reported at the moment. My understanding is our implementation chose the 3d alternative of GICV3 arch spec (6.3.2), ie. "the data that generated the error or errors is treated as having a legal value", increment the read cursor and currently we don't report any system error to the guest. Thanks Eric > > thanks > -- PMM >