From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoffer Dall <c.dall@virtualopensystems.com>
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>
Subject: Re: [PATCH 0/3] KVM_VCPU_GET_REG_LIST API
Date: Mon, 22 Oct 2012 13:39:06 +1030 [thread overview]
Message-ID: <87y5izi4od.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CANM98qKmEgAZ4-D+TsV+g74QF9TS_aOfoFfFC23rZrXgqLWFsg@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-10-22 3:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-05 7:58 [PATCH 0/3] KVM_VCPU_GET_REG_LIST API Rusty Russell
2012-09-05 7:58 ` [PATCH 1/3] KVM: Move KVM_SET_ONE_REG/KVM_GET_ONE_REG to generic code Rusty Russell
2012-09-19 14:17 ` Alexander Graf
2012-09-05 7:58 ` [PATCH 2/3] KVM: Add KVM_REG_SIZE() helper Rusty Russell
2012-09-19 14:18 ` Alexander Graf
2012-09-05 7:58 ` [PATCH 3/3] KVM: Add KVM_VCPU_GET_REG_LIST/KVM_CAP_REG_LIST Rusty Russell
2012-09-19 14:22 ` Alexander Graf
2012-10-10 18:12 ` Marcelo Tosatti
2012-10-11 8:11 ` Rusty Russell
2012-10-18 14:45 ` [PATCH 0/3] KVM_VCPU_GET_REG_LIST API Avi Kivity
2012-10-19 0:36 ` Rusty Russell
2012-10-19 6:19 ` Rusty Russell
2012-10-19 16:06 ` Christoffer Dall
2012-10-22 3:09 ` Rusty Russell [this message]
2012-10-22 17:45 ` Will Deacon
2012-10-22 18:11 ` Christoffer Dall
2012-10-24 11:25 ` RFC: Move kvm's instruction decoding into generic code Rusty Russell
2012-10-24 11:25 ` [PATCH 01/10] kvm: split out instruction structure from decoding method Rusty Russell
2012-10-24 11:25 ` [PATCH 02/10] kvm: split out instruction decode from emulation Rusty Russell
2012-10-24 11:25 ` [PATCH 03/10] kvm: split out instruction decode from emulation (thumb instructions) Rusty Russell
2012-10-24 11:25 ` [PATCH 04/10] kvm: completely separate decoding from execution Rusty Russell
2012-10-24 11:25 ` [PATCH 05/10] kvm: move instruction copying inside kvm_decode() Rusty Russell
2012-10-24 11:25 ` [PATCH 06/10] kvm: cleanup use of instr Rusty Russell
2012-10-24 11:25 ` [PATCH 07/10] kvm: clean up use of is_wide_instruction() Rusty Russell
2012-10-24 11:25 ` [PATCH 08/10] kvm: avoid using vcpu_cpsr() by passing down PSR Rusty Russell
2012-10-24 11:25 ` [PATCH 09/10] kvm: avoid reference vcpu->arch.hxfar by making thumb offset_addr relative Rusty Russell
2012-10-24 11:25 ` [PATCH 10/10] opcode: move generic instruction decode out of KVM Rusty Russell
2012-10-24 16:27 ` RFC: Move kvm's instruction decoding into generic code Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5izi4od.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=agraf@suse.de \
--cc=avi@redhat.com \
--cc=c.dall@virtualopensystems.com \
--cc=kvm@vger.kernel.org \
--cc=peter.maydell@linaro.org \
--cc=rusty.russell@linaro.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.