Re: Exposing host debug capabilities to userspace

[Alexander Graf <agraf@suse.de>]

On 24.11.14 13:53, Christoffer Dall wrote:
> On Mon, Nov 24, 2014 at 1:51 PM, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 24.11.14 13:44, Peter Maydell wrote:
>>> On 24 November 2014 at 12:41, Alexander Graf <agraf@suse.de> wrote:
>>>>> Am 24.11.2014 um 13:32 schrieb Peter Maydell <peter.maydell@linaro.org>:
>>>>> Yes, but we don't want to know about properties of the guest
>>>>> vCPU. In an ideal world QEMU could reserve say half the debug
>>>>> registers for debugging the VM on startup and have KVM expose
>>>>> ID registers indicating to the guest that it only had the
>>>>> other half...
>>>>
>>>> Yup, so create another (read-only) ONE_REG that exposes the number
>>>> of actual guest debug registers.
>>>
>>> I'm confused. ONE_REG is for guest state, and the ID register
>>> by definition is how we tell the guest how many debug registers
>>> it has. What we want to know (and perhaps even control) for
>>> debugging the VM is how many debug registers the host has.
>>
>> No, we don't want to know how many debug registers the host has. We want
>> to know how many debug registers the guest has.
>>
>> Imagine you're running on A57 today with 8 debug registers (no idea if
>> that's true, but assume it is). Tomorrow there will be a new core -
>> let's call it A67 - with 16 debug registers.
>>
>> To make sure your legacy, badly written guest behaves exactly the same -
>> especially after live migration - you want to spawn a VM with -cpu A57.
>> That implies you want to expose 8 debug registers into the guest. So
>> debug register synchronization should only be aware of those 8 registers.
>>
>> So what we really care about is the number of debug registers available
>> to a guest vcpu. That in turn means it's guest state and as such can
>> easily go into ONE_REG.
>>
> We already export this for the guest via ONE_REG.
> 
> What we want to do is support gdbstubs in QEMU to debug the guest, and
> to do this, QEMU needs to know how many hardware registers on the host
> there is; the guest will never see this information.
> 
> So this is really about the host, the guest side is trivially handled
> through ONE_REG.

That's the cp15 register that happens to get exposed to the guest. You
can just add another ONE_REG that does not have a cp15 equivalent to
expose the number of the vcpu's actually available debug registers.


Alex