Re: Exposing host debug capabilities to userspace

[Paolo Bonzini <pbonzini@redhat.com>]

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