From: Marc Zyngier <marc.zyngier@arm.com>
To: Jintack Lim <jintack@cs.columbia.edu>,
kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org
Cc: pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com,
andre.przywara@arm.com, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/8] Provide the EL1 physical timer to the VM
Date: Tue, 17 Jan 2017 17:09:12 +0000 [thread overview]
Message-ID: <b15297e4-1b30-27f8-dd43-fb1a85bd2cd5@arm.com> (raw)
In-Reply-To: <1482772326-29110-1-git-send-email-jintack@cs.columbia.edu>
On 26/12/16 17:11, 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.
>
> On VHE systems, this would be as simple as allowing full access to the
> EL1 physical timer to VMs because the KVM host does not use the EL1
> physical timer. However, on non-VHE systems, the KVM host already uses
> the EL1 physical timer which prevents us from granting full access of
> the EL1 physical timer to VMs.
>
> This patchset enables VMs to use the EL1 physical timer through
> trap-and-emulate. 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 patchset. This patchset will make it easy to add the
> EL2 timer support in the future, though.
>
> Note, Linux VMs booting in EL1 will be unaffected by this patch set and
> will continue to use only the virtual timer and this patch set will
> therefore not introduce any performance degredation as a result of
> trap-and-emulate.
Hi Jintack,
Any chance you could address Christoffer's comments and respin this
series? This looks like a good enhancement to our emulation, and
definitely a requirement for the nested work, so I'm obviously keen on it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2017-01-17 17:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-26 17:11 [RFC 0/8] Provide the EL1 physical timer to the VM Jintack Lim
2016-12-26 17:11 ` [RFC 1/8] KVM: arm/arm64: Abstract virtual timer context into separate structure Jintack Lim
2016-12-26 17:12 ` [RFC 2/8] KVM: arm/arm64: Decouple kvm timer functions from virtual timer Jintack Lim
2017-01-09 11:59 ` Christoffer Dall
2016-12-26 17:12 ` [RFC 3/8] KVM: arm/arm64: Add the EL1 physical timer context Jintack Lim
2016-12-26 17:12 ` [RFC 4/8] KVM: arm/arm64: Initialize the emulated EL1 physical timer Jintack Lim
2017-01-09 12:02 ` Christoffer Dall
2017-01-10 17:03 ` Jintack Lim
2017-01-10 19:34 ` Christoffer Dall
2017-01-10 20:22 ` Jintack Lim
2016-12-26 17:12 ` [RFC 5/8] KVM: arm64: Add the EL1 physical timer access handler Jintack Lim
2016-12-26 17:12 ` [RFC 6/8] KVM: arm/arm64: Update the physical timer interrupt level Jintack Lim
2017-01-09 12:14 ` Christoffer Dall
2017-01-10 17:27 ` Jintack Lim
2016-12-26 17:12 ` [RFC 7/8] KVM: arm/arm64: Set up a background timer for the physical timer emulation Jintack Lim
2017-01-09 12:13 ` Christoffer Dall
2017-01-10 18:47 ` Jintack Lim
2017-01-10 19:39 ` Christoffer Dall
2016-12-26 17:12 ` [RFC 8/8] KVM: arm/arm64: Emulate the EL1 phys timer register access Jintack Lim
2017-01-09 12:16 ` Christoffer Dall
2017-01-10 17:36 ` Jintack Lim
2017-01-10 19:40 ` Christoffer Dall
2017-01-10 20:10 ` Jintack Lim
2017-01-17 17:09 ` Marc Zyngier [this message]
2017-01-17 17:15 ` [RFC 0/8] Provide the EL1 physical timer to the VM Jintack Lim
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=b15297e4-1b30-27f8-dd43-fb1a85bd2cd5@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