Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf <agraf@suse.de>]

On 01.07.14 16:58, Scott Wood wrote:
> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>> To: Bhushan Bharat-R65777
>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>>>>> guest
>>>>>
>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>> -    if (vcpu->guest_debug) {
>>>>>> +    /*
>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>> +     */
>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>> Are you trying to allow the guest to be simultaneously debugged by itself and by
>>>>> host userspace?  How does this work?
>>>> Not actually, Currently we are not partitioning debug resources between
>>>> host userspace and guest. In fact we do not emulate debug registers for
>>>> guest. But we want host userspace to pass the interrupt to guest if it
>>>> is not able to handle.
>>> I don't understand the logic here.  A debug interrupt should be injected
>>> when the programming model in the guest says that a debug interrupt
>>> should happen.  How can that occur currently?  If the guest didn't set
>>> up the debug registers and QEMU still can't handle the debug interrupt,
>>> that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
>>> interrupt into the guest just adds another bug on top of that.
>> I don't think QEMU should be aware of these limitations.
> OK, but we should at least have some idea of how the whole thing is
> supposed to work, in order to determine if this is the correct behavior
> for QEMU.  I thought the model was that debug resources are either owned
> by QEMU or by the guest, and in the latter case, QEMU would never see
> the debug exception to begin with.

That's bad for a number of reasons. For starters it's different from how 
x86 handles debug registers - and I hate to be different just for the 
sake of being different. So if we do want to declare that debug 
registers are owned by either QEMU or the guest, we should change the 
semantics for all architectures.

The second problem I see is that we're disabling use cases for the sake 
of correctness. When I use gdbstub, I usually don't want anything in the 
way of debugging something - like if I want to debug the guest debugging 
itself for example.

So overall, I think the x86 approach is a nice middle ground between 
usability, performance and functionality.

>
>>>>> one reg?
>>>> We are using SREGS but if required we can use one_reg.
>>> I thought we were preferring one reg over sregs for new functionality.
>> I'm personally torn on this one. The problem here is that the sregs
>> fields and values are already reserved. For anything we don't have an
>> API for yet, yes, one_reg only. IIUC we have the API here, but were
>> lacking the implementation.
>  From a QEMU perspective, are we going to want to update this at the same
> time as everything else, or would jumping through sregs hoops be a
> nuisance?  Is the long term goal to have one reg support for everything?

Because we need to maintain backwards compatibility, I don't think we'll 
actually have any benefit from one reg support for everything.

I think we're in a path that is slow enough already to not worry about 
performance. I think we're good to just call the sregs setter on demand 
when we want to change single registers.


Alex