public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: zhaoshenglong@huawei•com (Shannon Zhao)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v4 18/21] KVM: ARM64: Add PMU overflow interrupt routing
Date: Wed, 2 Dec 2015 17:49:23 +0800	[thread overview]
Message-ID: <565EBEA3.8080500@huawei.com> (raw)
In-Reply-To: <565EAFC4.2040301@arm.com>



On 2015/12/2 16:45, Marc Zyngier wrote:
> On 02/12/15 02:40, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2015/12/2 0:57, Marc Zyngier wrote:
>>> >> On 01/12/15 16:26, Shannon Zhao wrote:
>>>> >>>
>>>> >>>
>>>> >>> On 2015/12/1 23:41, Marc Zyngier wrote:
>>>>>> >>>>> The reason is that when guest clear the overflow register, it will trap
>>>>>>> >>>>>> to kvm and call kvm_pmu_sync_hwstate() as you see above. At this moment,
>>>>>>> >>>>>> the overflow register is still overflowed(that is some bit is still 1).
>>>>>>> >>>>>> So We need to use some flag to mark we already inject this interrupt.
>>>>>>> >>>>>> And if during guest handling the overflow, there is a new overflow
>>>>>>> >>>>>> happening, the pmu->irq_pending will be set ture by
>>>>>>> >>>>>> kvm_pmu_perf_overflow(), then it needs to inject this new interrupt, right?
>>>>> >>>> I don't think so. This is a level interrupt, so the level should stay
>>>>> >>>> high as long as the guest hasn't cleared all possible sources for that
>>>>> >>>> interrupt.
>>>>> >>>>
>>>>> >>>> For your example, the guest writes to PMOVSCLR to clear the overflow
>>>>> >>>> caused by a given counter. If the status is now 0, the interrupt line
>>>>> >>>> drops. If the status is still non zero, the line stays high. And I
>>>>> >>>> believe that writing a 1 to PMOVSSET would actually trigger an
>>>>> >>>> interrupt, or keep it high if it has already high.
>>>>> >>>>
>>>> >>> Right, writing 1 to PMOVSSET will trigger an interrupt.
>>>> >>>
>>>>> >>>> In essence, do not try to maintain side state. I've been bitten.
>>>> >>>
>>>> >>> So on VM entry, it check if PMOVSSET is zero. If not, call 
>>>> >>> kvm_vgic_inject_irq to set the level high. If so, set the level low.
>>>> >>> On VM exit, it seems there is nothing to do.
>>> >>
>>> >> It is even simpler than that:
>>> >>
>>> >> - When you get an overflow, you inject an interrupt with the level set to 1.
>>> >> - When the overflow register gets cleared, you inject the same interrupt
>>> >> with the level set to 0.
>>> >>
>>> >> I don't think you need to do anything else, and the world switch should
>>> >> be left untouched.
>>> >>
>> > 
>> > On 2015/7/17 23:28, Christoffer Dall wrote:>> > +		
>> > kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>>>>> >>>> +					    pmu->irq_num, 1);
>>> >> what context is this overflow handler function?  kvm_vgic_inject_irq
>>> >> grabs a mutex, so it can sleep...
>>> >>
>>> >> from a quick glance at the perf core code, it looks like this is in
>>> >> interrupt context, so that call to kvm_vgic_inject_irq looks bad.
>>> >>
>> > 
>> > But as Christoffer said before, it's not good to call
>> > kvm_vgic_inject_irq directly in interrupt context. So if we just kick
>> > the vcpu here and call kvm_vgic_inject_irq on VM entry, is this fine?
> Possibly. I'm slightly worried that inject_irq itself is going to kick
> the vcpu again for no good reason. 
Yes, this will introduce a extra kick. What's the impact of kicking a
kicked vcpu?

> I guess we'll find out (and maybe
> we'll add a kvm_vgic_inject_irq_no_kick_please() helper...).
And add a parameter "bool kick" for vgic_update_irq_pending ?

-- 
Shannon

  reply	other threads:[~2015-12-02  9:49 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30  6:21 [PATCH v4 00/21] KVM: ARM64: Add guest PMU support Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 01/21] ARM64: Move PMU register related defines to asm/pmu.h Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 02/21] KVM: ARM64: Define PMU data structure for each vcpu Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 03/21] KVM: ARM64: Add offset defines for PMU registers Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 04/21] KVM: ARM64: Add reset and access handlers for PMCR_EL0 register Shannon Zhao
2015-11-30 18:11   ` Marc Zyngier
2015-10-30  6:21 ` [PATCH v4 05/21] KVM: ARM64: Add reset and access handlers for PMSELR register Shannon Zhao
2015-11-02 20:06   ` Christopher Covington
2015-11-30 17:56   ` Marc Zyngier
2015-12-01  1:51     ` Shannon Zhao
2015-12-01  8:49       ` Marc Zyngier
2015-12-01 12:46         ` Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 06/21] KVM: ARM64: Add reset and access handlers for PMCEID0 and PMCEID1 register Shannon Zhao
2015-11-30 11:42   ` Marc Zyngier
2015-11-30 11:59     ` Shannon Zhao
2015-11-30 13:19       ` Marc Zyngier
2015-10-30  6:21 ` [PATCH v4 07/21] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function Shannon Zhao
2015-11-02 20:13   ` Christopher Covington
2015-11-03  2:33     ` Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 08/21] KVM: ARM64: Add reset and access handlers for PMXEVTYPER register Shannon Zhao
2015-11-02 20:54   ` Christopher Covington
2015-11-03  2:41     ` Shannon Zhao
2015-11-30 18:12   ` Marc Zyngier
2015-12-01  2:42     ` Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 09/21] KVM: ARM64: Add reset and access handlers for PMXEVCNTR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 10/21] KVM: ARM64: Add reset and access handlers for PMCCNTR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 11/21] KVM: ARM64: Add reset and access handlers for PMCNTENSET and PMCNTENCLR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 12/21] KVM: ARM64: Add reset and access handlers for PMINTENSET and PMINTENCLR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 13/21] KVM: ARM64: Add reset and access handlers for PMOVSSET and PMOVSCLR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 14/21] KVM: ARM64: Add reset and access handlers for PMUSERENR register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 15/21] KVM: ARM64: Add reset and access handlers for PMSWINC register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 16/21] KVM: ARM64: Add access handlers for PMEVCNTRn and PMEVTYPERn register Shannon Zhao
2015-10-30  6:21 ` [PATCH v4 17/21] KVM: ARM64: Add helper to handle PMCR register bits Shannon Zhao
2015-11-02 21:20   ` Christopher Covington
2015-10-30  6:22 ` [PATCH v4 18/21] KVM: ARM64: Add PMU overflow interrupt routing Shannon Zhao
2015-10-30 12:08   ` kbuild test robot
2015-10-31  2:06     ` Shannon Zhao
2015-11-30 18:22   ` Marc Zyngier
2015-12-01 14:35     ` Shannon Zhao
2015-12-01 14:50       ` Marc Zyngier
2015-12-01 15:13         ` Shannon Zhao
2015-12-01 15:41           ` Marc Zyngier
2015-12-01 16:26             ` Shannon Zhao
2015-12-01 16:57               ` Marc Zyngier
2015-12-02  2:40                 ` Shannon Zhao
2015-12-02  8:45                   ` Marc Zyngier
2015-12-02  9:49                     ` Shannon Zhao [this message]
2015-12-02 10:22                       ` Marc Zyngier
2015-12-02 16:27                         ` Christoffer Dall
2015-10-30  6:22 ` [PATCH v4 19/21] KVM: ARM64: Reset PMU state when resetting vcpu Shannon Zhao
2015-10-30  6:22 ` [PATCH v4 20/21] KVM: ARM64: Free perf event of PMU when destroying vcpu Shannon Zhao
2015-10-30  6:22 ` [PATCH v4 21/21] KVM: ARM64: Add a new kvm ARM PMU device Shannon Zhao
2015-11-30 18:31   ` Marc Zyngier
2015-11-30 18:34 ` [PATCH v4 00/21] KVM: ARM64: Add guest PMU support Marc Zyngier
2015-12-01  1:52   ` Shannon Zhao

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=565EBEA3.8080500@huawei.com \
    --to=zhaoshenglong@huawei$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox