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
next prev parent reply other threads:[~2017-04-25 12:51 UTC|newest]
Thread overview: 18+ 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 ` [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:46 ` Marc Zyngier
2017-04-24 18:59 ` Daniel Lezcano
2017-04-24 19:14 ` Marc Zyngier
2017-04-24 19:59 ` Daniel Lezcano
2017-04-25 7:38 ` Marc Zyngier
2017-04-25 8:34 ` Daniel Lezcano
2017-04-25 9:10 ` Marc Zyngier
2017-04-25 9:49 ` Daniel Lezcano
2017-04-25 10:21 ` Marc Zyngier
2017-04-25 12:51 ` Daniel Lezcano [this message]
2017-04-25 13:22 ` Marc Zyngier
2017-04-25 13:53 ` Daniel Lezcano
2017-04-25 10:22 ` Christoffer Dall
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox