From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH 0/3] KVM_VCPU_GET_REG_LIST API
Date: Mon, 22 Oct 2012 13:39:06 +1030
Message-ID: <87y5izi4od.fsf@rustcorp.com.au>
References: <1346831926-31820-1-git-send-email-rusty.russell@linaro.org> <5080161C.9080209@redhat.com> <87objzpabx.fsf@rustcorp.com.au> <87vce72dc6.fsf@rustcorp.com.au> <CANM98qKmEgAZ4-D+TsV+g74QF9TS_aOfoFfFC23rZrXgqLWFsg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Avi Kivity <avi@redhat.com>,
	Rusty Russell <rusty.russell@linaro.org>, kvm@vger.kernel.org,
	Alexander Graf <agraf@suse.de>,
	Peter Maydell <peter.maydell@linaro.org>,
	"Will Deacon" <will.deacon@arm.com>
To: Christoffer Dall <c.dall@virtualopensystems.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from ozlabs.org ([203.10.76.45]:41872 "EHLO ozlabs.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932812Ab2JVDJn (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 21 Oct 2012 23:09:43 -0400
In-Reply-To: <CANM98qKmEgAZ4-D+TsV+g74QF9TS_aOfoFfFC23rZrXgqLWFsg@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Christoffer Dall <c.dall@virtualopensystems.com> writes:
> On Fri, Oct 19, 2012 at 2:19 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Wait, what?  kvm/arm isn't in kvm-next?
>> Christoffer, is there anything I can help with?
>
> Specifically there are worries about the instruction decoding for the
> mmio instructions. My cycles are unfortunately too limited to change
> this right now and I'm also not sure I agree things will turn out
> nicer by unifying all decoding into a large complicated space ship,
> but it would be great if you could take a look. This discussion seems
> to be a good place to start:
>
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-September/003447.html

They're still asking you to boil that ocean??

I could create a struct and do simple decode into it for limited cases
(ie. for kvm).  Will, do you want to see that?

But unifying them all is a much larger task, and only when that's all
done can you judge whether it was worthwhile.  I've spend half an hour
looking and each case is subtly different, and the conversion has to be
incredibly careful not to break them.  And converting opcodes.c is just
ideology; it's great as it is.

I'm interested in the 64-bit ARM kvm, because it would be nice to unify
the two implementations.  But the ABI will be different anyway (64 bit
regs get their own id space even if nothing else changes).

Let's get the current code shipped please, it's only going to bitrot
outside the tree.

Cheers,
Rusty.