Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx> writes: > On Fri, Oct 19, 2012 at 2:19 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
