From: Marc Zyngier <marc.zyngier@arm.com>
To: Jintack Lim <jintack@cs.columbia.edu>,
pbonzini@redhat.com, rkrcmar@redhat.com,
christoffer.dall@linaro.org, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com,
andre.przywara@arm.com, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org
Subject: Re: [RFC v4 00/10] Provide the EL1 physical timer to the VM
Date: Fri, 3 Feb 2017 16:14:18 +0000 [thread overview]
Message-ID: <11908d08-6e2d-010c-2e6f-fd677c7ad8b1@arm.com> (raw)
In-Reply-To: <1486135208-13415-1-git-send-email-jintack@cs.columbia.edu>
On 03/02/17 15:19, Jintack Lim wrote:
> The ARM architecture defines the EL1 physical timer and the virtual timer,
> and it is reasonable for an OS to expect to be able to access both.
> However, the current KVM implementation does not provide the EL1 physical
> timer to VMs but terminates VMs on access to the timer.
>
> This patch series enables VMs to use the EL1 physical timer through
> trap-and-emulate only on arm64. The KVM host emulates each EL1 physical
> timer register access and sets up the background timer accordingly. When
> the background timer expires, the KVM host injects EL1 physical timer
> interrupts to the VM. Alternatively, it's also possible to allow VMs to
> access the EL1 physical timer without trapping. However, this requires
> somehow using the EL2 physical timer for the Linux host while running the
> VM instead of the EL1 physical timer. Right now I just implemented
> trap-and-emulate because this was straightforward to do, and I leave it to
> future work to determine if transferring the EL1 physical timer state to
> the EL2 timer provides any performance benefit.
>
> This feature will be useful for any OS that wishes to access the EL1
> physical timer. Nested virtualization is one of those use cases. A nested
> hypervisor running inside a VM would think it has full access to the
> hardware and naturally tries to use the EL1 physical timer as Linux would
> do. Other nested hypervisors may try to use the EL2 physical timer as Xen
> would do, but supporting the EL2 physical timer to the VM is out of scope
> of this patch series. This patch series will make it easy to add the EL2
> timer support in the future, though.
>
> Note that Linux VMs booting in EL1 will be unaffected by this patch series
> and will continue to use only the virtual timer and this patch series will
> therefore not introduce any performance degredation as a result of
> trap-and-emulate.
>
> v3 => v4:
> - Fix a bug that prevents a VM from booting on 32-bit architecture
> - Clarify that the emulated physical timer is only supported on arm64
> in the cover letter
Hi Jintack,
I've now applied this to queue, and will push it out later today.
Out of curiosity, is there any reason why this is arm64 only? As far as
I can tell, we're only missing the cp15 handling (both for arm and in
the 32bit handling in arm64).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2017-02-03 16:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 15:19 Jintack Lim
2017-02-03 15:19 ` [RFC v4 01/10] KVM: arm/arm64: Abstract virtual timer context into separate structure Jintack Lim
2017-02-03 15:20 ` [RFC v4 02/10] KVM: arm/arm64: Move cntvoff to each timer context Jintack Lim
2017-02-03 15:20 ` [RFC v4 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer Jintack Lim
2017-02-03 15:20 ` [RFC v4 04/10] KVM: arm/arm64: Add the EL1 physical timer context Jintack Lim
2017-02-03 15:20 ` [RFC v4 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer Jintack Lim
2017-02-03 15:20 ` [RFC v4 06/10] KVM: arm/arm64: Update the physical timer interrupt level Jintack Lim
2017-02-03 15:20 ` [RFC v4 07/10] KVM: arm/arm64: Set a background timer to the earliest timer expiration Jintack Lim
2017-02-03 15:20 ` [RFC v4 08/10] KVM: arm/arm64: Set up a background timer for the physical timer emulation Jintack Lim
2017-02-03 15:20 ` [RFC v4 09/10] KVM: arm64: Add the EL1 physical timer access handler Jintack Lim
2017-02-03 15:20 ` [RFC v4 10/10] KVM: arm/arm64: Emulate the EL1 phys timer registers Jintack Lim
2017-02-03 16:14 ` Marc Zyngier [this message]
2017-02-03 16:51 ` [RFC v4 00/10] Provide the EL1 physical timer to the VM Jintack Lim
2017-02-03 16:54 ` Marc Zyngier
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=11908d08-6e2d-010c-2e6f-fd677c7ad8b1@arm.com \
--to=marc.zyngier@arm.com \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=jintack@cs.columbia.edu \
--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@armlinux.org.uk \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=will.deacon@arm.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
all inboxes | Powered by JetHome®