From: Marc Zyngier <maz@kernel.org>
To: Beata Michalska <beata.michalska@linaro.org>
Cc: kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 0/2] KVM: arm: fix KVM_CAP_ARM_INJECT_EXT_DABT for aarch32 guests
Date: Sun, 26 Jan 2020 11:56:02 +0000 [thread overview]
Message-ID: <20200126115602.6e67b11b@why> (raw)
In-Reply-To: <CADSWDzubQHvG8_c6a7E=basbtXxW-7u_ZVRz6+M7zGOAYYxz7A@mail.gmail.com>
On Fri, 24 Jan 2020 15:39:29 +0000
Beata Michalska <beata.michalska@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.morse@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
next prev parent reply other threads:[~2020-01-26 11:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 12:33 [PATCH 0/2] KVM: arm: fix KVM_CAP_ARM_INJECT_EXT_DABT for aarch32 guests James Morse
2020-01-21 12:33 ` [PATCH 1/2] KVM: arm: fix DFSR setting for non-LPAE " James Morse
2020-01-21 12:33 ` [PATCH 2/2] KVM: arm: Make inject_abt32() inject an external abort instead James Morse
2020-01-21 13:45 ` [PATCH 0/2] KVM: arm: fix KVM_CAP_ARM_INJECT_EXT_DABT for aarch32 guests Marc Zyngier
2020-01-24 15:39 ` Beata Michalska
2020-01-26 11:56 ` Marc Zyngier [this message]
2020-01-27 13:46 ` Beata Michalska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200126115602.6e67b11b@why \
--to=maz@kernel.org \
--cc=beata.michalska@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox