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

[Alexander Graf <agraf@suse.de>]

On 02.07.14 19:28, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Bhushan Bharat-R65777
>> Sent: Wednesday, July 02, 2014 5:07 PM
>> To: Wood Scott-B07421; Alexander Graf
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Tuesday, July 01, 2014 10:11 PM
>>> To: Alexander Graf
>>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
>>> kvm@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>> injection to guest
>>>
>>> On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
>>>> On 01.07.14 17:35, Scott Wood wrote:
>>>>> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
>>>>>> On 01.07.14 16:58, Scott Wood wrote:
>>>>>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>>>>>>> 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.
>>>>> How does it work on x86?
>>>> It overwrites more-or-less random breakpoints with its own ones, but
>>>> leaves the others intact ;).
>>> Are you talking about software breakpoints or management of hardware
>>> debug registers?
>>>
>>>>>> 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.
>>>>> If we want to say that ownership of the registers is shared, we
>>>>> need a plan for how that would actually work.
>>>> I think you're overengineering here :). When do people actually use
>>>> gdbstub? Usually when they want to debug a broken guest. We can
>>>> either
>>>>
>>>>     * overengineer heavily and reduce the number of registers
>>>> available to the guest to always have spares
>>>>     * overengineer a bit and turn off guest debugging completely when
>>>> we use gdbstub
>>>>     * just leave as much alive as we can, hoping that it helps with
>>>> the debugging
>>>>
>>>> Option 3 is what x86 does - and I think it's a reasonable approach.
>>>> This is not an interface that needs to be 100% consistent and bullet
>>>> proof, it's a best effort to enable you to debug as much as possible.
>>> I'm not insisting on 100% -- just hoping for some
>>> explanation/discussion about how it's intended to work for the cases where it
>> can.
>>> How will MSR[DE] and MSRP[DEP] be handled?
>>>
>>> How would I go about telling QEMU/KVM that I don't want this shared
>>> mode, because I don't want guest to interfere with the debugging I'm
>>> trying to do from QEMU?
>>>
>>> Will guest accesses to debug registers cause a userspace exit when
>>> guest_debug is enabled?
>>>
>>>>>> I think we're in a path that is slow enough already to not worry
>>>>>> about performance.
>>>>> It's not just about performance, but simplicity of use, and
>>>>> consistency of API.
>>>>>
>>>>> Oh, and it looks like there already exist one reg definitions and
>>>>> implementations for most of the debug registers.
>>>> For BookE? Where?
>>> arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn
>> I tried to quickly prototype what I think we want to do (this is not tested)
> Hi Scott,
>
> There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions:
> - As qemu is also using debug resource,  We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts.
> - Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE.
> - If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs)
> - Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE).

Yeah, and with this everything falls apart. I guess we can't share 
hardware debug resources after all then. So yes, let's declare all 
hardware debug facilities QEMU owned as soon as QEMU starts using gdbstub.


Alex