From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@redhat.com (Auger Eric) Date: Wed, 26 Apr 2017 11:57:16 +0200 Subject: [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation In-Reply-To: <20170426084830.GB2098@work-vm> 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> Message-ID: <4dc866a0-582c-af69-916f-eb435988b5ec@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Peter, Dave, On 26/04/2017 10:48, Dr. David Alan Gilbert wrote: > * Peter Maydell (peter.maydell at linaro.org) wrote: >> On 26 April 2017 at 09:26, Auger Eric wrote: >>> On 25/04/2017 12:43, Peter Maydell wrote: >>>> When does the -EFAULT return happen? (if the guest points GITS_BASER >>>> etc at invalid memory, presumably?) >>> >>> Yes that's correct, when GICR_PENDBASER contains a bad GPA. >>> >>>> How does the QEMU migration code >>>> handle this case? Failing migration because the guest has done something >>>> silly doesn't seem too palatable, but trying to avoid that could be >>>> more effort than an obscure corner case really merits. >>> >>> The kvm_device_access will cause an abort() as for other errors returned >>> by kvm_device_ioctl(). >> >> That's pretty nasty. Guests shouldn't be able to provoke QEMU >> into abort()ing, ideally. We don't necessarily have to produce >> a successful migration, but we should at least fail it cleanly. > > Yes, no abort()'s during migration due to guest behaviour. > They always end up coming back around to being filed as migration > bugs and people worry why they've got cores. > > Ideally log a message into stderr to say that the guest state > is inconsistent so that when someone comes to debug it then they > can see it's obvious. OK I agree. I will respin the QEMU part accordingly and in that situation I won't abort and will print a message. Thanks Eric > > Dave > >> thanks >> -- PMM > -- > Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >