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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to