From: Christoffer Dall <cdall@linaro.org>
To: Jintack Lim <jintack@cs.columbia.edu>
Cc: kvm@vger.kernel.org, marc.zyngier@arm.com,
catalin.marinas@arm.com, will.deacon@arm.com,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [RFC v3 00/10] Provide the EL1 physical timer to the VM
Date: Thu, 2 Feb 2017 13:31:04 +0100 [thread overview]
Message-ID: <20170202123104.GJ27852@cbox> (raw)
In-Reply-To: <1485970990-13775-1-git-send-email-jintack@cs.columbia.edu>
Hi Jintack,
On Wed, Feb 01, 2017 at 12:43:00PM -0500, 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. 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.
>
> v2 => v3:
> - Rebase on kvmarm/queue
> - Take kvm->lock to synchronize cntvoff across all vtimers
> - Remove unnecessary function parameters
> - Add comments
I just gave v3 a test run on my TC2 (32-bit platform) and my guest
quickly locks up trying to run cyclictest or when booting the machine it
stalls with RCU timeouts.
Could you have a look?
Thanks,
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v3 00/10] Provide the EL1 physical timer to the VM
Date: Thu, 2 Feb 2017 13:31:04 +0100 [thread overview]
Message-ID: <20170202123104.GJ27852@cbox> (raw)
In-Reply-To: <1485970990-13775-1-git-send-email-jintack@cs.columbia.edu>
Hi Jintack,
On Wed, Feb 01, 2017 at 12:43:00PM -0500, 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. 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.
>
> v2 => v3:
> - Rebase on kvmarm/queue
> - Take kvm->lock to synchronize cntvoff across all vtimers
> - Remove unnecessary function parameters
> - Add comments
I just gave v3 a test run on my TC2 (32-bit platform) and my guest
quickly locks up trying to run cyclictest or when booting the machine it
stalls with RCU timeouts.
Could you have a look?
Thanks,
-Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <cdall@linaro.org>
To: Jintack Lim <jintack@cs.columbia.edu>
Cc: pbonzini@redhat.com, rkrcmar@redhat.com,
christoffer.dall@linaro.org, marc.zyngier@arm.com,
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 v3 00/10] Provide the EL1 physical timer to the VM
Date: Thu, 2 Feb 2017 13:31:04 +0100 [thread overview]
Message-ID: <20170202123104.GJ27852@cbox> (raw)
In-Reply-To: <1485970990-13775-1-git-send-email-jintack@cs.columbia.edu>
Hi Jintack,
On Wed, Feb 01, 2017 at 12:43:00PM -0500, 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. 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.
>
> v2 => v3:
> - Rebase on kvmarm/queue
> - Take kvm->lock to synchronize cntvoff across all vtimers
> - Remove unnecessary function parameters
> - Add comments
I just gave v3 a test run on my TC2 (32-bit platform) and my guest
quickly locks up trying to run cyclictest or when booting the machine it
stalls with RCU timeouts.
Could you have a look?
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-02-02 12:30 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 17:43 [RFC v3 00/10] Provide the EL1 physical timer to the VM Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` [RFC v3 01/10] KVM: arm/arm64: Abstract virtual timer context into separate structure Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` [RFC v3 02/10] KVM: arm/arm64: Move cntvoff to each timer context Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:03 ` Christoffer Dall
2017-02-02 10:03 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:04 ` Christoffer Dall
2017-02-02 10:04 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 04/10] KVM: arm/arm64: Add the EL1 physical timer context Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:15 ` Christoffer Dall
2017-02-02 10:15 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:15 ` Christoffer Dall
2017-02-02 10:15 ` Christoffer Dall
2017-02-02 10:15 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 06/10] KVM: arm/arm64: Update the physical timer interrupt level Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:15 ` Christoffer Dall
2017-02-02 10:15 ` Christoffer Dall
2017-02-02 10:15 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 07/10] KVM: arm/arm64: Set a background timer to the earliest timer expiration Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:30 ` Christoffer Dall
2017-02-02 10:30 ` Christoffer Dall
2017-02-02 10:30 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 08/10] KVM: arm/arm64: Set up a background timer for the physical timer emulation Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:30 ` Christoffer Dall
2017-02-02 10:30 ` Christoffer Dall
2017-02-02 10:30 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 09/10] KVM: arm64: Add the EL1 physical timer access handler Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:31 ` Christoffer Dall
2017-02-02 10:31 ` Christoffer Dall
2017-02-02 10:31 ` Christoffer Dall
2017-02-01 17:43 ` [RFC v3 10/10] KVM: arm/arm64: Emulate the EL1 phys timer registers Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-01 17:43 ` Jintack Lim
2017-02-02 10:31 ` Christoffer Dall
2017-02-02 10:31 ` Christoffer Dall
2017-02-02 10:31 ` Christoffer Dall
2017-02-02 12:31 ` Christoffer Dall [this message]
2017-02-02 12:31 ` [RFC v3 00/10] Provide the EL1 physical timer to the VM Christoffer Dall
2017-02-02 12:31 ` Christoffer Dall
2017-02-02 14:51 ` Jintack Lim
2017-02-02 14:51 ` Jintack Lim
2017-02-02 14:51 ` Jintack Lim
2017-02-02 15:08 ` Christoffer Dall
2017-02-02 15:08 ` Christoffer Dall
2017-02-02 15:08 ` Christoffer Dall
2017-02-03 12:33 ` Christoffer Dall
2017-02-03 12:33 ` Christoffer Dall
2017-02-03 12:33 ` Christoffer Dall
2017-02-03 13:14 ` Jintack Lim
2017-02-03 13:14 ` Jintack Lim
2017-02-03 13:14 ` Jintack Lim
2017-02-03 13:34 ` Christoffer Dall
2017-02-03 13:34 ` Christoffer Dall
2017-02-03 13:34 ` Christoffer Dall
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=20170202123104.GJ27852@cbox \
--to=cdall@linaro.org \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--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=marc.zyngier@arm.com \
--cc=pbonzini@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 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.