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: Tue, 25 Apr 2017 14:51:03 +0200 [thread overview]
Message-ID: <20170425125103.GC16888@mai> (raw)
In-Reply-To: <c98a5ff3-c2ea-5f94-d136-391bd7c224f3@arm.com>
On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
> On 25/04/17 10:49, Daniel Lezcano wrote:
> > On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>
> [...]
>
> >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> >>> +{
> >>> + /*
> >>> + * We don't need the measurement because the idle code already
> >>> + * knows the next expiry event.
> >>> + */
> >>> + if (act->flags & __IRQF_TIMER)
> >>> + return;
> >>
> >> And that's where this is really wrong for the KVM guest timer. As I
> >> said, this timer is under complete control of the guest, and the rest of
> >> the system doesn't know about it. KVM itself will only find out when the
> >> vcpu does a VM exit for a reason or another, and will just save/restore
> >> the state in order to be able to give the timer to another guest.
> >>
> >> The idle code is very much *not* aware of anything concerning that guest
> >> timer.
> >
> > Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> > at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
> >
> > The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> > timer is under control of VM2 and will expire at <time+delta>.
> >
> > Is the host wake up with the SW timer and switch in VM1 which in turn restores
> > the timer and jump in the virtual timer irq handler?
>
> Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
> (preempting VM2) or on another. The timer is then restored with the
> pending virtual interrupt injected, and the guest does what it has to
> with it.
Thanks for clarification.
So there is a virtual timer with real registers / interruption (waking up the
host) for the running VMs and SW timers for non-running VMs.
What is the benefit of having such mechanism instead of real timers injecting
interrupts in the VM without the virtual timer + save/restore? Efficiency in
the running VMs when setting up timers (saving privileges change overhead)?
--
<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: Tue, 25 Apr 2017 14:51:03 +0200 [thread overview]
Message-ID: <20170425125103.GC16888@mai> (raw)
In-Reply-To: <c98a5ff3-c2ea-5f94-d136-391bd7c224f3@arm.com>
On Tue, Apr 25, 2017@11:21:21AM +0100, Marc Zyngier wrote:
> On 25/04/17 10:49, Daniel Lezcano wrote:
> > On Tue, Apr 25, 2017@10:10:12AM +0100, Marc Zyngier wrote:
>
> [...]
>
> >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> >>> +{
> >>> + /*
> >>> + * We don't need the measurement because the idle code already
> >>> + * knows the next expiry event.
> >>> + */
> >>> + if (act->flags & __IRQF_TIMER)
> >>> + return;
> >>
> >> And that's where this is really wrong for the KVM guest timer. As I
> >> said, this timer is under complete control of the guest, and the rest of
> >> the system doesn't know about it. KVM itself will only find out when the
> >> vcpu does a VM exit for a reason or another, and will just save/restore
> >> the state in order to be able to give the timer to another guest.
> >>
> >> The idle code is very much *not* aware of anything concerning that guest
> >> timer.
> >
> > Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> > at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
> >
> > The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> > timer is under control of VM2 and will expire at <time+delta>.
> >
> > Is the host wake up with the SW timer and switch in VM1 which in turn restores
> > the timer and jump in the virtual timer irq handler?
>
> Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
> (preempting VM2) or on another. The timer is then restored with the
> pending virtual interrupt injected, and the guest does what it has to
> with it.
Thanks for clarification.
So there is a virtual timer with real registers / interruption (waking up the
host) for the running VMs and SW timers for non-running VMs.
What is the benefit of having such mechanism instead of real timers injecting
interrupts in the VM without the virtual timer + save/restore? Efficiency in
the running VMs when setting up timers (saving privileges change overhead)?
--
<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: Tue, 25 Apr 2017 14:51:03 +0200 [thread overview]
Message-ID: <20170425125103.GC16888@mai> (raw)
In-Reply-To: <c98a5ff3-c2ea-5f94-d136-391bd7c224f3@arm.com>
On Tue, Apr 25, 2017 at 11:21:21AM +0100, Marc Zyngier wrote:
> On 25/04/17 10:49, Daniel Lezcano wrote:
> > On Tue, Apr 25, 2017 at 10:10:12AM +0100, Marc Zyngier wrote:
>
> [...]
>
> >>> +static inline void setup_timings(struct irq_desc *desc, struct irqaction *act)
> >>> +{
> >>> + /*
> >>> + * We don't need the measurement because the idle code already
> >>> + * knows the next expiry event.
> >>> + */
> >>> + if (act->flags & __IRQF_TIMER)
> >>> + return;
> >>
> >> And that's where this is really wrong for the KVM guest timer. As I
> >> said, this timer is under complete control of the guest, and the rest of
> >> the system doesn't know about it. KVM itself will only find out when the
> >> vcpu does a VM exit for a reason or another, and will just save/restore
> >> the state in order to be able to give the timer to another guest.
> >>
> >> The idle code is very much *not* aware of anything concerning that guest
> >> timer.
> >
> > Just for my own curiosity, if there are two VM (VM1 and VM2). VM1 sets a timer1
> > at <time> and exits, VM2 runs and sets a timer2 at <time+delta>.
> >
> > The timer1 for VM1 is supposed to expire while VM2 is running. IIUC the virtual
> > timer is under control of VM2 and will expire at <time+delta>.
> >
> > Is the host wake up with the SW timer and switch in VM1 which in turn restores
> > the timer and jump in the virtual timer irq handler?
>
> Indeed. The SW timer causes VM1 to wake-up, either on the same CPU
> (preempting VM2) or on another. The timer is then restored with the
> pending virtual interrupt injected, and the guest does what it has to
> with it.
Thanks for clarification.
So there is a virtual timer with real registers / interruption (waking up the
host) for the running VMs and SW timers for non-running VMs.
What is the benefit of having such mechanism instead of real timers injecting
interrupts in the VM without the virtual timer + save/restore? Efficiency in
the running VMs when setting up timers (saving privileges change overhead)?
--
<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
next prev parent reply other threads:[~2017-04-25 12:51 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
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 [this message]
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=20170425125103.GC16888@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.