On Thu, Jun 7, 2018 at 12:01 PM Will Deacon <will.dea...@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 <ler...@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
