Hi Marc, On Sun, 26 Jan 2020 at 11:56, Marc Zyngier <maz@xxxxxxxxxx> wrote: > > On Fri, 24 Jan 2020 15:39:29 +0000 > Beata Michalska <beata.michalska@xxxxxxxxxx> wrote: > > Hi Beata, > > > Hi James, > > > > Thanks for the fixes - they work like a charm. > > > > On Tue, 21 Jan 2020 at 12:34, James Morse <james.morse@xxxxxxx> wrote: > > > > > > Beata reports that KVM_CAP_ARM_INJECT_EXT_DABT doesn't do the expected > > > thing for aarch32 guests. We get the wrong register layout, and weren't > > > even trying to set a 'external abort' in the first place! > > > > > > Both patches are intended as fixes, but patch 2 is somewhat in the eye > > > of the beholder. I don't know why an imp-def exception was picked... > > > > > On a side note - currently KVM exposes capability that is not fully supported > > (till the fix gets applied) and there is no easy way for the user space to > > determine whether the injection will work as expected and whether it is safe to > > use it or not. Although this is addressing a problem that is not that common > > (I suppose) but still it might be worth to add a way for the kernel to inform > > the user-space that it is all good to go? There has been a 'similar' case in the > > past with KVM_SET_USER_MEMORY_REGION, where fixes where needed > > and those were announced through new caps. Now, I'm not sure if adding new > > capability would be the best approach here though it seems that there is not > > much of a choice? > > My take on this particular issue is that although the functionality is > not perfectly working (far from it), it isn't completely broken (the > guest does get some form of abort). Furthermore, we tend to add this > kind of discovery mechanism when the userspace interface is broken, not > when we have an implementation defect in the CPU emulation. > Indeed, the guest will get 'the' abort with a small catch though: the fault handler will actually manage to handle it leading to the faulting instruction being restarted, trapping thereby the guest in a vicious circle. This is trading in abnormal termination of the guest (aka 'no idea what has just happened' ) for rather meaningless back-and-forth with the host kernel. > The real question is whether there anything out there that would depend > on such broken behaviour? > AFAICT, that would be Qemu trying to handle 'nicely' all the unexpected cases, where guest triggers the DABT with no valid instruction syndrome (changes on the way). Now, I agree this is not the most common case ever, but still. Currently the guest will keep on repeating the same mistake ... until it gets told it's high time to stop trying. And that becomes arbitrary without implementing some additional logic behind it - a bit of an overkill. BR Beata > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
