On Fri, 24 Jan 2020 15:39:29 +0000
Beata Michalska <beata.michal...@linaro.org> 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.mo...@arm.com> 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.
The real question is whether there anything out there that would depend
on such broken behaviour?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
