From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [kvmarm] [PATCH v5 13/14] KVM: ARM: Handle I/O aborts Date: Mon, 14 Jan 2013 19:53:14 +0100 Message-ID: <50F4541A.9030702@suse.de> References: <20130108183811.46302.58543.stgit@ubuntu> <20130108184005.46302.38495.stgit@ubuntu> <20130114164326.GH23505@n2100.arm.linux.org.uk> <20130114184319.GN23505@n2100.arm.linux.org.uk> <20130114185038.GJ31341@mudshark.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Russell King - ARM Linux , "kvm@vger.kernel.org" , Marc Zyngier , Marcelo Tosatti , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" To: Will Deacon Return-path: Received: from cantor2.suse.de ([195.135.220.15]:41134 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755255Ab3ANSxU (ORCPT ); Mon, 14 Jan 2013 13:53:20 -0500 In-Reply-To: <20130114185038.GJ31341@mudshark.cambridge.arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/14/2013 07:50 PM, Will Deacon wrote: > On Mon, Jan 14, 2013 at 06:43:19PM +0000, Russell King - ARM Linux wrote: >> On Mon, Jan 14, 2013 at 01:25:39PM -0500, Christoffer Dall wrote: >>> However, unifying all instruction decoding within arch/arm is quite >>> the heavy task, and requires agreeing on some canonical API that >>> people can live with and it will likely take a long time. I seem to >>> recall there were also arguments against unifying kprobe code with >>> other instruction decoding, as the kprobe code was also written to >>> work highly optimized under certain assumptions, if I understood >>> previous comments correctly. >> Yes, I know Rusty had a go. >> >> What I think may make sense is to unify this and the alignment code. >> They're really after the same things, which are: >> >> - Given an instruction, and register set, calculate the address of the >> access, size, number of accesses, and the source/destination registers. >> - Update the register set as though the instruction had been executed >> by the CPU. >> >> However, I've changed tack slightly from the above in the last 10 minutes >> or so. I'm thinking a little more that we might be able to take what we >> already have in alignment.c and provide it with a set of accessors >> according to size etc. > FWIW, KVM only needs this code for handling complex MMIO instructions, which > aren't even generated by recent guest kernels. I'm inclined to suggest removing > this emulation code from KVM entirely given that it's likely to bitrot as > it is executed less and less often. That'd mean that you heavily limit what type of guests you're executing, which I don't think is a good idea. Alex