Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Jun 7, 2018 at 12:01 PM Will Deacon <will.deacon@arm.com> wrote:
>
> On Thu, Jun 07, 2018 at 09:48:50AM +0200, Christoffer Dall wrote:
> > [+Will]
> >
> > On Tue, Jun 05, 2018 at 03:07:14PM +0200, Laszlo Ersek wrote:
> > > On 06/05/18 13:30, Richard Biener wrote:
> > > > On Mon, Jun 4, 2018 at 8:11 PM Laszlo Ersek <lersek@redhat.com> wrote:
> > > >>
> > > >> Hi!
> > > >>
> > > >> Apologies if this isn't the right place for asking. For the problem
> > > >> statement, I'll simply steal Ard's writeup [1]:
> > > >>
> > > >>> KVM on ARM refuses to decode load/store instructions used to perform
> > > >>> I/O to emulated devices, and instead relies on the exception syndrome
> > > >>> information to describe the operand register, access size, etc. This
> > > >>> is only possible for instructions that have a single input/output
> > > >>> register (as opposed to ones that increment the offset register, or
> > > >>> load/store pair instructions, etc). Otherwise, QEMU crashes with the
> > > >>> following error
> > > >>>
> > > >>>   error: kvm run failed Function not implemented
> > > >>>   [...]
> > > >>>   QEMU: Terminated
> > > >>>
> > > >>> and KVM produces a warning such as the following in the kernel log
> > > >>>
> > > >>>   kvm [17646]: load/store instruction decoding not implemented
> > > >
> > > > This looks like a kvm/qemu issue to me.  Whatever that exception syndrome
> > > > thing is, it surely has a pointer to the offending instruction it could decode?
> > >
> > > I believe so -- the instruction decoding is theoretically possible (to
> > > my understanding); KVM currently doesn't do it because it's super
> > > complex (again, to my understanding).
> > >
> > The instruction decoding was considered and discarded because the
> > understanding at the time was that any instruction that didn't generate
> > valid decoding hints in the syndrome register (such as multiple output
> > register operations) would not be safe to use on device memory, and
> > therefore shouldn't be used neither on real hardware nor in VM guests.
> >
> > If this still holds, it's not a question of an architecture bug or a
> > missing feature in KVM, but a question of a guest doing something wrong.
> >
> > I added Will here, because he provided the rationale for why the premise
> > held last we discussed this, and he may be able to update us on that.
>
> This was years ago, so my memory is a little hazy. I think there are broadly
> two categories:
>
>   1. Code using stuff like LDM for device memory access.
>   2. Code using writeback addressing modes for device memory access.
>
> (1) is generally going to be unsafe because you lose atomicity guarantees
> and you might end up making multiple accesses to the device.

So we might want to avoid these for volatile accesses then (if we
don't already).
> (2) isn't
> unsafe, but means that the hypervisor needs to implement expensive (and
> very rarely used) instruction emulation to deal with the writeback. Most
> people would then want to fix their guest instead.

And here we may want to offer a -mno-volatile-autoinc-foo option to
disable using those instructions for volatile accesses?  Or maybe
generally though that's probably pushing it a bit.

Richard.

> Will