All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: tglx@linutronix.de, "Mark Rutland" <mark.rutland@arm.com>,
	"Vineet Gupta" <vgupta@synopsys.com>,
	"Patrice Chotard" <patrice.chotard@st.com>,
	"Kukjin Kim" <kgene@kernel.org>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Javier Martinez Canillas" <javier@osg.samsung.com>,
	"Christoffer Dall" <christoffer.dall@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	kernel@stlinux.com, linux-samsung-soc@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
Date: Mon, 24 Apr 2017 20:59:09 +0200	[thread overview]
Message-ID: <20170424185909.GD2137@mai> (raw)
In-Reply-To: <398f3f3d-c567-0f1f-1a43-9b8d5805d5fd@arm.com>

On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> On 24/04/17 15:01, Daniel Lezcano wrote:
> > In the next changes, we track when the interrupts occur in order to
> > statistically compute when is supposed to happen the next interrupt.
> > 
> > In all the interruptions, it does not make sense to store the timer interrupt
> > occurences and try to predict the next interrupt as when know the expiration
> > time.
> > 
> > The request_irq() has a irq flags parameter and the timer drivers use it to
> > pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> > Based on this flag, we can discard these interrupts when tracking them.
> > 
> > But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> > if the interrupt type is a timer.
> > 
> > Add a function request_percpu_irq_flags() where we can specify the flags. The
> > request_percpu_irq() function is changed to be a wrapper to
> > request_percpu_irq_flags() passing a zero flag parameter.
> > 
> > Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> > instead with the IRQF_TIMER flag set.
> > 
> > For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> > flag (or zero) is a valid parameter to be passed to the
> > request_percpu_irq_flags() function.
> 
> [...]
> 
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 35d7100..602e0a8 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> >  		host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> >  	}
> >  
> > -	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> > -				 "kvm guest timer", kvm_get_running_vcpus());
> > +	err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> > +				       IRQF_TIMER, "kvm guest timer",
> > +				       kvm_get_running_vcpus());
> >  	if (err) {
> >  		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> >  			host_vtimer_irq, err);
> > 
> 
> How is that useful? This timer is controlled by the guest OS, and not
> the host kernel. Can you explain how you intend to make use of that
> information in this case?

Isn't it a source of interruption on the host kernel?

-- 

 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
Date: Mon, 24 Apr 2017 20:59:09 +0200	[thread overview]
Message-ID: <20170424185909.GD2137@mai> (raw)
In-Reply-To: <398f3f3d-c567-0f1f-1a43-9b8d5805d5fd@arm.com>

On Mon, Apr 24, 2017@07:46:43PM +0100, Marc Zyngier wrote:
> On 24/04/17 15:01, Daniel Lezcano wrote:
> > In the next changes, we track when the interrupts occur in order to
> > statistically compute when is supposed to happen the next interrupt.
> > 
> > In all the interruptions, it does not make sense to store the timer interrupt
> > occurences and try to predict the next interrupt as when know the expiration
> > time.
> > 
> > The request_irq() has a irq flags parameter and the timer drivers use it to
> > pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> > Based on this flag, we can discard these interrupts when tracking them.
> > 
> > But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> > if the interrupt type is a timer.
> > 
> > Add a function request_percpu_irq_flags() where we can specify the flags. The
> > request_percpu_irq() function is changed to be a wrapper to
> > request_percpu_irq_flags() passing a zero flag parameter.
> > 
> > Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> > instead with the IRQF_TIMER flag set.
> > 
> > For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> > flag (or zero) is a valid parameter to be passed to the
> > request_percpu_irq_flags() function.
> 
> [...]
> 
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 35d7100..602e0a8 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> >  		host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> >  	}
> >  
> > -	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> > -				 "kvm guest timer", kvm_get_running_vcpus());
> > +	err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> > +				       IRQF_TIMER, "kvm guest timer",
> > +				       kvm_get_running_vcpus());
> >  	if (err) {
> >  		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> >  			host_vtimer_irq, err);
> > 
> 
> How is that useful? This timer is controlled by the guest OS, and not
> the host kernel. Can you explain how you intend to make use of that
> information in this case?

Isn't it a source of interruption on the host kernel?

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
Date: Mon, 24 Apr 2017 20:59:09 +0200	[thread overview]
Message-ID: <20170424185909.GD2137@mai> (raw)
In-Reply-To: <398f3f3d-c567-0f1f-1a43-9b8d5805d5fd@arm.com>

On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> On 24/04/17 15:01, Daniel Lezcano wrote:
> > In the next changes, we track when the interrupts occur in order to
> > statistically compute when is supposed to happen the next interrupt.
> > 
> > In all the interruptions, it does not make sense to store the timer interrupt
> > occurences and try to predict the next interrupt as when know the expiration
> > time.
> > 
> > The request_irq() has a irq flags parameter and the timer drivers use it to
> > pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> > Based on this flag, we can discard these interrupts when tracking them.
> > 
> > But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> > if the interrupt type is a timer.
> > 
> > Add a function request_percpu_irq_flags() where we can specify the flags. The
> > request_percpu_irq() function is changed to be a wrapper to
> > request_percpu_irq_flags() passing a zero flag parameter.
> > 
> > Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> > instead with the IRQF_TIMER flag set.
> > 
> > For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> > flag (or zero) is a valid parameter to be passed to the
> > request_percpu_irq_flags() function.
> 
> [...]
> 
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 35d7100..602e0a8 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> >  		host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> >  	}
> >  
> > -	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> > -				 "kvm guest timer", kvm_get_running_vcpus());
> > +	err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> > +				       IRQF_TIMER, "kvm guest timer",
> > +				       kvm_get_running_vcpus());
> >  	if (err) {
> >  		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> >  			host_vtimer_irq, err);
> > 
> 
> How is that useful? This timer is controlled by the guest OS, and not
> the host kernel. Can you explain how you intend to make use of that
> information in this case?

Isn't it a source of interruption on the host kernel?

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2017-04-24 18:59 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 14:01 [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request Daniel Lezcano
2017-04-24 14:01 ` Daniel Lezcano
2017-04-24 14:01 ` Daniel Lezcano
2017-04-24 14:01 ` [PATCH V9 2/3] irq: Track the interrupt timings Daniel Lezcano
2017-04-24 14:01 ` [PATCH V9 3/3] irq: Compute the periodic interval for interrupts Daniel Lezcano
2017-04-24 18:33 ` [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request Krzysztof Kozlowski
2017-04-24 18:33   ` Krzysztof Kozlowski
2017-04-24 18:33   ` Krzysztof Kozlowski
2017-04-24 18:46 ` Marc Zyngier
2017-04-24 18:46   ` Marc Zyngier
2017-04-24 18:46   ` Marc Zyngier
2017-04-24 18:59   ` Daniel Lezcano [this message]
2017-04-24 18:59     ` Daniel Lezcano
2017-04-24 18:59     ` Daniel Lezcano
2017-04-24 19:14     ` Marc Zyngier
2017-04-24 19:14       ` Marc Zyngier
2017-04-24 19:14       ` Marc Zyngier
2017-04-24 19:59       ` Daniel Lezcano
2017-04-24 19:59         ` Daniel Lezcano
2017-04-24 19:59         ` Daniel Lezcano
2017-04-24 19:59         ` Daniel Lezcano
2017-04-25  7:38         ` Marc Zyngier
2017-04-25  7:38           ` Marc Zyngier
2017-04-25  7:38           ` Marc Zyngier
2017-04-25  8:34           ` Daniel Lezcano
2017-04-25  8:34             ` Daniel Lezcano
2017-04-25  8:34             ` Daniel Lezcano
2017-04-25  8:34             ` Daniel Lezcano
2017-04-25  9:10             ` Marc Zyngier
2017-04-25  9:10               ` Marc Zyngier
2017-04-25  9:10               ` Marc Zyngier
2017-04-25  9:10               ` Marc Zyngier
2017-04-25  9:49               ` Daniel Lezcano
2017-04-25  9:49                 ` Daniel Lezcano
2017-04-25  9:49                 ` Daniel Lezcano
2017-04-25  9:49                 ` Daniel Lezcano
2017-04-25 10:21                 ` Marc Zyngier
2017-04-25 10:21                   ` Marc Zyngier
2017-04-25 10:21                   ` Marc Zyngier
2017-04-25 12:51                   ` Daniel Lezcano
2017-04-25 12:51                     ` Daniel Lezcano
2017-04-25 12:51                     ` Daniel Lezcano
2017-04-25 13:22                     ` Marc Zyngier
2017-04-25 13:22                       ` Marc Zyngier
2017-04-25 13:22                       ` Marc Zyngier
2017-04-25 13:22                       ` Marc Zyngier
2017-04-25 13:53                       ` Daniel Lezcano
2017-04-25 13:53                         ` Daniel Lezcano
2017-04-25 13:53                         ` Daniel Lezcano
2017-04-25 10:22                 ` Christoffer Dall
2017-04-25 10:22                   ` Christoffer Dall
2017-04-25 10:22                   ` Christoffer Dall
2017-04-25 10:22                   ` Christoffer Dall
2017-04-25 12:52                   ` Daniel Lezcano
2017-04-25 12:52                     ` Daniel Lezcano
2017-04-25 12:52                     ` Daniel Lezcano

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=20170424185909.GD2137@mai \
    --to=daniel.lezcano@linaro.org \
    --cc=christoffer.dall@linaro.org \
    --cc=javier@osg.samsung.com \
    --cc=kernel@stlinux.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=patrice.chotard@st.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vgupta@synopsys.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.