kvmclock provides the behaviour sched_clock users expect.
Mark it as stable allowing nohz_full in guests.
See individual patches for more details.
v2: address comments from Paolo:
- set COUNTS_FROM_ZERO unconditionally (host).
- rely on KVM_FEATURE_CLOCKSOURCE_STABLE_BIT (guest).
On Wed, May 27, 2015 at 08:32:04AM +0300, Avi Kivity wrote:
On 05/27/2015 05:06 AM, Steve Rutherford wrote:
On Sun, May 24, 2015 at 07:46:03PM +0300, Avi Kivity wrote:
On 05/13/2015 04:47 AM, Steve Rutherford wrote:
Adds KVM_EXIT_IOAPIC_EOI which passes the interrupt vector up to
userspace.
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/x86/kvm/x86.c |4
1 file
From: Luiz Capitulino lcapitul...@redhat.com
If you try to enable NOHZ_FULL on a guest today, you'll get
the following error when the guest tries to deactivate the
scheduler tick:
WARNING: CPU: 3 PID: 2182 at kernel/time/tick-sched.c:192
can_stop_full_tick+0xb9/0x290()
NO_HZ FULL will not
Until now we have been calling kvm_guest_exit after re-enabling
interrupts when we come back from the guest, but this has the
unfortunate effect that CPU time accounting done in the context of timer
interrupts occurring while the guest is running doesn't properly notice
that the time since the
Setting sched clock stable for kvmclock causes the printk timestamps
to not start from zero, which is different from baremetal and
can possibly break userspace. Add a flag to indicate that
hypervisor sets clock base at zero when kvmclock is initialized.
Signed-off-by: Marcelo Tosatti
On 28/05/2015 03:46, Marcelo Tosatti wrote:
+ flags = PVCLOCK_COUNTS_FROM_ZERO;
If the KVM_FEATURE_CLOCKSOURCE_STABLE_BIT bit is not set, we cannot
trust flags at all. So let's just do...
if (kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE_STABLE_BIT))
-
On 28/05/2015 03:47, Marcelo Tosatti wrote:
Initialize kvmclock base, on kvmclock system MSR write time,
so that the guest sees kvmclock counting from zero.
This matches baremetal behaviour when kvmclock in guest
sets sched clock stable.
Signed-off-by: Marcelo Tosatti
On 27/05/2015 19:05, Paolo Bonzini wrote:
This patch includes changes to the external API for SMM support.
All the changes are predicated by the availability of a new
capability, KVM_CAP_X86_SMM, which is added at the end of the
patch series.
Signed-off-by: Paolo Bonzini
The elr_el2 and spsr_el2 registers in fact contain the processor state
before entry into the hypervisor code. In the case of guest state it
could be in either el0 or el1.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
arch/arm64/kvm/hyp.S | 8
1 file changed, 4 insertions(+), 4
Until now we have been calling kvm_guest_exit after re-enabling
interrupts when we come back from the guest, but this has the
unfortunate effect that CPU time accounting done in the context of timer
interrupts doesn't properly notice that the time since the last tick was
spent in the guest.
2015-05-28 11:00+0200, Paolo Bonzini:
On 27/05/2015 19:05, Paolo Bonzini wrote:
This patch includes changes to the external API for SMM support.
All the changes are predicated by the availability of a new
capability, KVM_CAP_X86_SMM, which is added at the end of the
patch series.
On Thu, May 28, 2015 at 02:49:09PM +0200, Christoffer Dall wrote:
Until now we have been calling kvm_guest_exit after re-enabling
interrupts when we come back from the guest, but this has the
unfortunate effect that CPU time accounting done in the context of timer
interrupts doesn't properly
13 matches
Mail list logo
