All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>,
	Scott Wood <scottwood@freescale.com>
Cc: "kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest
Date: Tue, 01 Jul 2014 10:48:18 +0000	[thread overview]
Message-ID: <53B291F2.2080707@suse.de> (raw)
In-Reply-To: <8680485fcf45425a8a19099f0d544a75@DM2PR03MB574.namprd03.prod.outlook.com>


On 01.07.14 12:30, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 3:42 PM
>> To: Bhushan Bharat-R65777; Wood Scott-B07421
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Tuesday, July 01, 2014 11:53 AM
>>>> To: Wood Scott-B07421
>>>> 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
>>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>>>          /*
>>>>>>>>           * Since there is no shadow MSR, sync MSR_DE into the
>>>>>>>> guest @@
>>>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>>>> kvm_vcpu
>>>>>>> *vcpu)
>>>>>>>>      clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>>>
>>>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>>>> +
>>>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>>>> guest_debug unset) on e500v2?
>>>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>>>> emulated).
>>>>> How is it useful to inject a debug exception into the guest, until
>>>>> these things are emulated?
>>>> We don't have to touch QEMU later then ;). But I agree that it would
>>>> make a lot of sense to enable guest debugging along the way - it can't be
>> that hard, no?
>>> Copy pasting my response in another email:
>>>
>>> "
>>> Ok, Till we add support for guest to used debug resource, can we say that
>> userspace will still try to inject debug interrupt (as it does not know guest
>> capability) to guest but KVM will:
>>>    - clear guest dbsr
>> Can we fake the value of DBSR that the guest sees?
> Yes; we can hack the dbsr emulation with a comment :)
> But why we want that?

I guess I don't fully grasp what you're proposing :).


Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>,
	Scott Wood <scottwood@freescale.com>
Cc: "kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest
Date: Tue, 01 Jul 2014 12:48:18 +0200	[thread overview]
Message-ID: <53B291F2.2080707@suse.de> (raw)
In-Reply-To: <8680485fcf45425a8a19099f0d544a75@DM2PR03MB574.namprd03.prod.outlook.com>


On 01.07.14 12:30, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 3:42 PM
>> To: Bhushan Bharat-R65777; Wood Scott-B07421
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Tuesday, July 01, 2014 11:53 AM
>>>> To: Wood Scott-B07421
>>>> 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
>>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>>>          /*
>>>>>>>>           * Since there is no shadow MSR, sync MSR_DE into the
>>>>>>>> guest @@
>>>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>>>> kvm_vcpu
>>>>>>> *vcpu)
>>>>>>>>      clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>>>
>>>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>>>> +
>>>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>>>> guest_debug unset) on e500v2?
>>>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>>>> emulated).
>>>>> How is it useful to inject a debug exception into the guest, until
>>>>> these things are emulated?
>>>> We don't have to touch QEMU later then ;). But I agree that it would
>>>> make a lot of sense to enable guest debugging along the way - it can't be
>> that hard, no?
>>> Copy pasting my response in another email:
>>>
>>> "
>>> Ok, Till we add support for guest to used debug resource, can we say that
>> userspace will still try to inject debug interrupt (as it does not know guest
>> capability) to guest but KVM will:
>>>    - clear guest dbsr
>> Can we fake the value of DBSR that the guest sees?
> Yes; we can hack the dbsr emulation with a comment :)
> But why we want that?

I guess I don't fully grasp what you're proposing :).


Alex

  reply	other threads:[~2014-07-01 10:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27  6:25 [PATCH 0/2] KVM: powerpc/booke: Debug interrupt injection to guest Bharat Bhushan
2014-06-27  6:37 ` Bharat Bhushan
2014-06-27  6:25 ` [PATCH 1/2] KVM: powerpc/booke: allow debug interrupt at "debug level" Bharat Bhushan
2014-06-27  6:37   ` Bharat Bhushan
2014-06-27  6:25 ` [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest Bharat Bhushan
2014-06-27  6:37   ` Bharat Bhushan
2014-06-27 18:23   ` Scott Wood
2014-06-27 18:23     ` Scott Wood
2014-06-30  4:38     ` Bharat.Bhushan
2014-06-30  4:38       ` Bharat.Bhushan
2014-06-30 20:25       ` Scott Wood
2014-06-30 20:25         ` Scott Wood
2014-07-01  5:40         ` Bharat.Bhushan
2014-07-01  5:40           ` Bharat.Bhushan
2014-07-01  6:23         ` Alexander Graf
2014-07-01  6:23           ` Alexander Graf
2014-07-01 10:06           ` Bharat.Bhushan
2014-07-01 10:06             ` Bharat.Bhushan
2014-07-01 10:12             ` Alexander Graf
2014-07-01 10:12               ` Alexander Graf
2014-07-01 10:30               ` Bharat.Bhushan
2014-07-01 10:30                 ` Bharat.Bhushan
2014-07-01 10:48                 ` Alexander Graf [this message]
2014-07-01 10:48                   ` Alexander Graf
2014-07-01 14:58           ` Scott Wood
2014-07-01 14:58             ` Scott Wood
2014-07-01 15:04             ` Alexander Graf
2014-07-01 15:04               ` Alexander Graf
2014-07-01 15:35               ` Scott Wood
2014-07-01 15:35                 ` Scott Wood
2014-07-01 16:22                 ` Alexander Graf
2014-07-01 16:22                   ` Alexander Graf
2014-07-01 16:40                   ` Scott Wood
2014-07-01 16:40                     ` Scott Wood
2014-07-02 11:37                     ` Bharat.Bhushan
2014-07-02 11:37                       ` Bharat.Bhushan
2014-07-02 17:28                     ` Bharat.Bhushan
2014-07-02 17:28                       ` Bharat.Bhushan
2014-07-03 11:36                       ` Alexander Graf
2014-07-03 11:36                         ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53B291F2.2080707@suse.de \
    --to=agraf@suse.de \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.