From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH 14/15] KVM: ARM: Handle I/O aborts Date: Mon, 8 Oct 2012 17:52:05 -0400 Message-ID: References: <20120915153359.21241.86002.stgit@ubuntu> <20120915153559.21241.29970.stgit@ubuntu> <20120927151108.GM25916@mudshark.cambridge.arm.com> <20121001125326.GA2100@linaro.org> <20121005090025.GK4625@n2100.arm.linux.org.uk> <20121008100412.GA2302@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Russell King - ARM Linux , Tixy , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "kvm@vger.kernel.org" , "kvmarm@lists.cs.columbia.edu" To: Dave Martin Return-path: Received: from mail-vc0-f174.google.com ([209.85.220.174]:41339 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026Ab2JHVwG (ORCPT ); Mon, 8 Oct 2012 17:52:06 -0400 Received: by mail-vc0-f174.google.com with SMTP id fo13so5294828vcb.19 for ; Mon, 08 Oct 2012 14:52:05 -0700 (PDT) In-Reply-To: <20121008100412.GA2302@linaro.org> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Oct 8, 2012 at 6:04 AM, Dave Martin wrote: > On Fri, Oct 05, 2012 at 10:00:25AM +0100, Russell King - ARM Linux wrote: >> On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote: >> > A good starting point would be load/store emulation as this seems to be a >> > common theme, and we would need a credible deployment for any new >> > framework so that we know it's fit for purpose. >> >> Probably not actually, that code is written to be fast, because things >> like IP stack throughput depend on it - particularly when your network >> card can only DMA packets to 32-bit aligned addresses (resulting in >> virtually all network data being misaligned.) > > A fair point, but surely it would still be worth a try? > > We might decide that a few particular cases of instruction decode > should not use the generic framework for performance reaons, but in > most cases being critically dependent on fault-driven software > emulation for performance would be a serious mistake in the first place > (discussions about the network code notwithstanding). > > This is not an argument for being slower just for the sake of it, but > it can make sense to factor code on paths where performance is not an > issue. > I'm all for unifying this stuff, but I still think it doesn't qualify for holding back on merging KVM patches. The ARM mode instruction decoding can definitely be cleaned up though to look more like the Thumb2 mode decoding which will be a good step before refactoring to use a more common framework. Currently we decode too many types of instructions (not just the ones with cleared HSR.IV) in ARM mode, so the whole complexity of that code can be reduced. I'll give that a go before re-sending the KVM patch series. -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: c.dall@virtualopensystems.com (Christoffer Dall) Date: Mon, 8 Oct 2012 17:52:05 -0400 Subject: [PATCH 14/15] KVM: ARM: Handle I/O aborts In-Reply-To: <20121008100412.GA2302@linaro.org> References: <20120915153359.21241.86002.stgit@ubuntu> <20120915153559.21241.29970.stgit@ubuntu> <20120927151108.GM25916@mudshark.cambridge.arm.com> <20121001125326.GA2100@linaro.org> <20121005090025.GK4625@n2100.arm.linux.org.uk> <20121008100412.GA2302@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 8, 2012 at 6:04 AM, Dave Martin wrote: > On Fri, Oct 05, 2012 at 10:00:25AM +0100, Russell King - ARM Linux wrote: >> On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote: >> > A good starting point would be load/store emulation as this seems to be a >> > common theme, and we would need a credible deployment for any new >> > framework so that we know it's fit for purpose. >> >> Probably not actually, that code is written to be fast, because things >> like IP stack throughput depend on it - particularly when your network >> card can only DMA packets to 32-bit aligned addresses (resulting in >> virtually all network data being misaligned.) > > A fair point, but surely it would still be worth a try? > > We might decide that a few particular cases of instruction decode > should not use the generic framework for performance reaons, but in > most cases being critically dependent on fault-driven software > emulation for performance would be a serious mistake in the first place > (discussions about the network code notwithstanding). > > This is not an argument for being slower just for the sake of it, but > it can make sense to factor code on paths where performance is not an > issue. > I'm all for unifying this stuff, but I still think it doesn't qualify for holding back on merging KVM patches. The ARM mode instruction decoding can definitely be cleaned up though to look more like the Thumb2 mode decoding which will be a good step before refactoring to use a more common framework. Currently we decode too many types of instructions (not just the ones with cleared HSR.IV) in ARM mode, so the whole complexity of that code can be reduced. I'll give that a go before re-sending the KVM patch series. -Christoffer