On Wed, Apr 26, 2017 at 11:57:16AM +0200, Auger Eric wrote: > Hi Peter, Dave, > > On 26/04/2017 10:48, Dr. David Alan Gilbert wrote: > > * Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > >> On 26 April 2017 at 09:26, Auger Eric <eric.auger@xxxxxxxxxx> wrote: > >>> On 25/04/2017 12:43, Peter Maydell wrote: > >>>> When does the -EFAULT return happen? (if the guest points GITS_BASER<n> > >>>> 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. > 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. Just a thought. Thanks, -Christoffer
