> > > What about using the ehpriv instruction (defined in 2.06)? > > > We could define a unique "qemu software breakpoint", and the > > > hypervisor's ehpriv handler will be able to easily distinguish them. > > > > > > On e500v2, this would be an illegal instruction. > > > > > > We don't need to worry about a conflict with future opcodes and it > > > seems like the whole point of ehpriv being defined-- to let a > > > hypervisor define special opcodes for stuff like this. > > > > Yes, it even states so in the little box below the description. Very > > good catch! > > > > > If we use trap, we will need the list of patched IPs in > > > the kernel. ehpriv avoids the need for that. > > > > Well, the way it's handled on x86 now is that the kernel asks user > > space if it knows about the breakpoint and if not user space reinjects > > the debug interrupt into the guest. > > > > Is there anything that ensures us BookS won't use 31/270? > > I will check with the Freescale instruction set architect.
Talked to the ISA architect and he says--- ...In general the architecture will not overlay opcodes until all the opcode space has been exhausted, and even then its probably not likely. So, it seems highly unlikely that the 31/270 will ever be used for something else. So, it sounds like ehpriv is the way to go. Stuart -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
