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:

quoted

* Peter Maydell (peter.maydell at linaro.org) wrote:

quoted

On 26 April 2017 at 09:26, Auger Eric [off-list ref] wrote:

quoted

On 25/04/2017 12:43, Peter Maydell wrote:

quoted

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.

quoted

 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