[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170425125241.GD16888@mai>
Date: Tue, 25 Apr 2017 14:52:41 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Christoffer Dall <cdall@...aro.org>
Cc: Marc Zyngier <marc.zyngier@....com>, tglx@...utronix.de,
Mark Rutland <mark.rutland@....com>,
Vineet Gupta <vgupta@...opsys.com>,
Patrice Chotard <patrice.chotard@...com>,
Kukjin Kim <kgene@...nel.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Javier Martinez Canillas <javier@....samsung.com>,
Christoffer Dall <christoffer.dall@...aro.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-snps-arc@...ts.infradead.org, kernel@...inux.com,
linux-samsung-soc@...r.kernel.org, kvmarm@...ts.cs.columbia.edu,
kvm@...r.kernel.org
Subject: Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with
percpu irq request
On Tue, Apr 25, 2017 at 12:22:30PM +0200, Christoffer Dall wrote:
> On Tue, Apr 25, 2017 at 11:49:27AM +0200, Daniel Lezcano wrote:
>
> [...]
>
> > >
> > > 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?
> >
> The thing that may be missing here is that a VCPU thread (more of which
> in a collection is a VM) is just a thread from the point of view of
> Linux, and whether or not a guest schedules a timer, should not effect
> the scheduler's decision to run a given thread, if the thread is
> runnable.
>
> Whenever we run a VCPU thread, we look at its timer state (in software)
> and calculate if the guest should see a timer interrupt and inject such
> a one (the hardware arch timer is not involved in this process at all).
>
> We use timers in exactly two scenarios:
>
> 1. The hardware arch timers are used to force an exit to the host when
> the guest programmed the timer, so we can do the calculation in
> software I mentioned above and inject a virtual software-generated
> interrupt when the guest expects to see one.
>
> 2. The guest goes to sleep (WFI) but has programmed a timer to be woken
> up at some point. KVM handles a WFI by blocking the VCPU thread,
> which basically means making the thread interruptible and putting it
> on a waitqueue. In this case we schedule a software timer to make
> the thread runnable again when the software timer fires (and the
> scheduler runs that thread when it wants to after that).
>
> If you have a VCPU thread from VM1 blocked, and you run a VCPU thread
> from VM2, then the VCPU thread from VM2 will program the hardware arch
> timer with the context of the VM2 VCPU thread while running, and this
> has nothing to do with the VCPU thread from VM1 at this point, because
> it relies on the host Linux time keeping infrastructure to become
> runnable some time in the future, and running a guest naturally doesn't
> mess with the host's time keeping.
>
> Hope this helps,
Yes, definitively. Thanks for the detailed description.
-- Daniel
--
<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
Powered by blists - more mailing lists