On 24/11/2014 15:52, Christoffer Dall wrote: > > We had a lenghty IRC discussion on this, for the curious, go read it > here: > http://irclogs.linaro.org/2014/11/24/%23kvm-arm.html Some notes... > chazy but saying that you want to design an ABI that potentially exposes fewer debug registers to gdbstubs than your hardware supports and breaks gdbstub support if you happen to support emulation of a cpu with more debug registers in the future, because you want to re-use ONE_REG is not a great approach either > > agraf chazy: but you wouldn't even remotely think of doing it, no? > > agraf chazy: I'm saying that QEMU shouldn't have access to the excess registers > > chazy agraf: I wouldn’t even remotely think of doing nested virtualization, but people have > > agraf chazy: QEMU spawns an A57, it gets 8 debug registers > > chazy agraf: I understand, but I don’t agree with your rationale > > agraf chazy: not "QEMU spawns an A57 on an A67, so it gets 8 real and 8 hidden debug registers that it also needs to be aware of mappings of" I disagree with Alex. QEMU can use the 16 debug registers as it wishes, since it sets them with KVM_SET_GUEST_DEBUG. The guest's eight can be mapped to the last 8 if those are the required semantics for the architecture. Just exit to QEMU if you do a debug register write while gdbstub debugging is active; QEMU gets the contents of the 8 VCPU-visible registers with ONE_REG (equivalent of x86 GET_DEBUGREGS); calls KVM_SET_GUEST_DEBUG to reflect them in the 16-register state; and restarts. It works as long as you can trap both reads and writes. > chazy ajb-linaro: don’t migrate a guest that is getting debugged is > the answer to that one I believe > > ajb-linaro chazy: at least with the overlay approach that happens automatically > > ajb-linaro the overlay isn't migrated and the new host isn't calling SET_GUEST_DEBUG so whatever the debug registers where before are restorerd Right. The destination will lose the hardware breakpoints/watchpoints because it starts the guest with KVM_SET_GUEST_DEBUG. Apart from losing them, everything should work fine. The dest sets the 8 VCPU-visible registers with ONE_REG, the hypervisor reflects them in a subset of the 16 physical registers, and "that's it". Paolo -- 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
