kvm: Drop unused kvm_pit_in_kernel

PATCH In review Jan Kiszka 5 participants 12 messages Mar 21, 2012 – Apr 11, 2012 KVM

lore

Share & tools

lore

Jan Kiszka

author

2012-03-21 12:36 UTC #0 lore raw

PATCH 1/1 kvm: Drop unused kvm_pit_in_kernel

This is now implied by kvm_irqchip_in_kernel.

Signed-off-by Jan Kiszka <[email protected]>

---
 kvm-all.c  |    6 ------
 kvm-stub.c |    6 ------
 kvm.h      |    2 --
 3 files changed, 0 insertions(+), 14 deletions(-)

kvm-all.c +0 -6

index 21c7dd2..7f8c188 100644
@@ -75,7 +75,6 @@ struct KVMState
 #ifdef KVM_CAP_SET_GUEST_DEBUG
     struct kvm_sw_breakpoint_head kvm_sw_breakpoints;
 #endif
-    int pit_in_kernel;
     int pit_state2;
     int xsave, xcrs;
     int many_ioeventfds;

@@ -195,11 +194,6 @@ static void kvm_reset_vcpu(void *opaque)
     kvm_arch_reset_vcpu(env);
 }
 
-int kvm_pit_in_kernel(void)
-{
-    return kvm_state->pit_in_kernel;
-}
-
 int kvm_init_vcpu(CPUState *env)
 {
     KVMState *s = kvm_state;

kvm-stub.c +0 -6

index 1f1c686..fab3ab1 100644
@@ -16,12 +16,6 @@
 #include "gdbstub.h"
 #include "kvm.h"
 
-int kvm_pit_in_kernel(void)
-{
-    return 0;
-}
-
-
 int kvm_init_vcpu(CPUState *env)
 {
     return -ENOSYS;

kvm.h +0 -2

index 8ef4476..128cc8f 100644
@@ -83,8 +83,6 @@ int kvm_update_guest_debug(CPUState *env, unsigned long reinject_trap);
 int kvm_set_signal_mask(CPUState *env, const sigset_t *sigset);
 #endif
 
-int kvm_pit_in_kernel(void);
-
 int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr);
 int kvm_on_sigbus(int code, void *addr);

Signature · 1 line

1.7.3.4

Avi Kivity

2012-03-21 13:36 UTC #1 lore raw

Quoted 3 lines · Jan Kiszka

This is now implied by kvm_irqchip_in_kernel.

So we can't have -no-kvm-pit?

No huge loss, but unexpected.

Signature · 1 line

error compiling committee.c: too many arguments to function

Jan Kiszka

author

2012-03-21 13:39 UTC #2 lore raw

Quoted 8 lines · Avi Kivity

Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
So we can't have -no-kvm-pit?
No huge loss, but unexpected.

See e81dda195556e72f8cd294998296c1051aab30a8.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Gleb Natapov

2012-03-21 13:42 UTC #3 lore raw

Quoted 6 lines · Jan Kiszka

Quoted 5 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.

Quoted 6 lines

Quoted 3 lines
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
See e81dda195556e72f8cd294998296c1051aab30a8.

I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?

--
Gleb.

Jan Kiszka

author

2012-03-21 13:49 UTC #4 lore raw

Quoted 7 lines · Gleb Natapov

Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?

It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Gleb Natapov

2012-03-22 07:18 UTC #5 lore raw

Quoted 12 lines · Jan Kiszka

Quoted 11 lines · Gleb Natapov
Quoted 10 lines · Jan Kiszka
Quoted 8 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
So we can't have -no-kvm-pit?
No huge loss, but unexpected.

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?
It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393

Hmm, may be we should think about this some more. If in the (not so far) future we want to drop pit emulation from the kernel we may want to support -no-kvm-pit to allow migration from old kernels to new one.

--
Gleb.

Jan Kiszka

author

2012-03-22 12:41 UTC #6 lore raw

Quoted 18 lines · Gleb Natapov

Quoted 17 lines · Jan Kiszka
Quoted 15 lines · Gleb Natapov
Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
Quoted 6 lines
Quoted 3 lines
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?

Quoted 6 lines

Quoted 3 lines
It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393
Hmm, may be we should think about this some more. If in the (not so far) future we want to drop pit emulation from the kernel we may want to support -no-kvm-pit to allow migration from old kernels to new one.

That's not an issue. Both device models are compatible, and you can migrate between kernel_irqchip=on/off theses days with QEMU.

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Gleb Natapov

2012-03-22 12:52 UTC #7 lore raw

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Gleb Natapov
Quoted 20 lines · Jan Kiszka
Quoted 7 lines · Gleb Natapov
Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?
It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393

Quoted 7 lines

Quoted 3 lines
Hmm, may be we should think about this some more. If in the (not so far) future we want to drop pit emulation from the kernel we may want to support -no-kvm-pit to allow migration from old kernels to new one.
That's not an issue. Both device models are compatible, and you can migrate between kernel_irqchip=on/off theses days with QEMU.

Cool. Including PIT lost tick compensation?

--
Gleb.

Jan Kiszka

author

2012-03-22 13:27 UTC #8 lore raw

Quoted 23 lines · Gleb Natapov

Quoted 22 lines · Jan Kiszka
Quoted 21 lines · Gleb Natapov
Quoted 20 lines · Jan Kiszka
Quoted 7 lines · Gleb Natapov
Quoted 6 lines · Jan Kiszka
Quoted 5 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?
It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393

Quoted 8 lines

Quoted 7 lines
Quoted 3 lines
Hmm, may be we should think about this some more. If in the (not so far) future we want to drop pit emulation from the kernel we may want to support -no-kvm-pit to allow migration from old kernels to new one.
That's not an issue. Both device models are compatible, and you can migrate between kernel_irqchip=on/off theses days with QEMU.
Cool. Including PIT lost tick compensation?

The feature is not yet available for the userspace PIT (we only support tick compensation for the userspace RTC - IIRC). Requires better IRQ injection feedback, you likely remember. ;)

Also, I wonder if the kernel exports all tick-compensation related states for save/restore. Need to check again...

Jan

Signature · 2 lines

Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Gleb Natapov

2012-03-27 10:48 UTC #9 lore raw

Quoted 28 lines · Jan Kiszka

Quoted 27 lines · Gleb Natapov
Quoted 26 lines · Jan Kiszka
Quoted 24 lines · Gleb Natapov
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Gleb Natapov
Quoted 10 lines · Jan Kiszka
Quoted 8 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
This is now implied by kvm_irqchip_in_kernel.
So we can't have -no-kvm-pit?
No huge loss, but unexpected.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
See e81dda195556e72f8cd294998296c1051aab30a8.
I am curious what is the reason for upstream to not supporting disabling the in-kernel PIT separately?
It was considered no longer relevant:
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/85393
Hmm, may be we should think about this some more. If in the (not so far) future we want to drop pit emulation from the kernel we may want to support -no-kvm-pit to allow migration from old kernels to new one.

Quoted 9 lines

Quoted 4 lines
Quoted 3 lines
That's not an issue. Both device models are compatible, and you can migrate between kernel_irqchip=on/off theses days with QEMU.
Cool. Including PIT lost tick compensation?
The feature is not yet available for the userspace PIT (we only support tick compensation for the userspace RTC - IIRC). Requires better IRQ injection feedback, you likely remember. ;)

Unfortunately I do, no matter how hard I try to forget :)

Quoted 3 lines

Also, I wonder if the kernel exports all tick-compensation related states for save/restore. Need to check again...

Looks like it does not.

--
Gleb.

Jan Kiszka

2012-03-21 23:00 UTC #10 lore raw

PATCH v2 1/1 kvm: Drop unused kvm_pit_in_kernel

In reply to Jan Kiszka

From: Jan Kiszka <[email protected]>

This is now implied by kvm_irqchip_in_kernel.

Signed-off-by Jan Kiszka <[email protected]>

---

Rebased over latest uq/master.

 kvm-all.c  |    6 ------
 kvm-stub.c |    6 ------
 kvm.h      |    2 --
 3 files changed, 0 insertions(+), 14 deletions(-)

kvm-all.c +0 -6

index ba2cee1..3a1fa40 100644
@@ -75,7 +75,6 @@ struct KVMState
 #ifdef KVM_CAP_SET_GUEST_DEBUG
     struct kvm_sw_breakpoint_head kvm_sw_breakpoints;
 #endif
-    int pit_in_kernel;
     int pit_state2;
     int xsave, xcrs;
     int many_ioeventfds;

@@ -198,11 +197,6 @@ static void kvm_reset_vcpu(void *opaque)
     kvm_arch_reset_vcpu(env);
 }
 
-int kvm_pit_in_kernel(void)
-{
-    return kvm_state->pit_in_kernel;
-}
-
 int kvm_init_vcpu(CPUArchState *env)
 {
     KVMState *s = kvm_state;

kvm-stub.c +0 -6

index 69a1228..ec8fe74 100644
@@ -16,12 +16,6 @@
 #include "gdbstub.h"
 #include "kvm.h"
 
-int kvm_pit_in_kernel(void)
-{
-    return 0;
-}
-
-
 int kvm_init_vcpu(CPUArchState *env)
 {
     return -ENOSYS;

kvm.h +0 -2

index 330f17b..55f107d 100644
@@ -83,8 +83,6 @@ int kvm_update_guest_debug(CPUArchState *env, unsigned long reinject_trap);
 int kvm_set_signal_mask(CPUArchState *env, const sigset_t *sigset);
 #endif
 
-int kvm_pit_in_kernel(void);
-
 int kvm_on_sigbus_vcpu(CPUArchState *env, int code, void *addr);
 int kvm_on_sigbus(int code, void *addr);

Marcelo Tosatti

Applied

2012-04-11 01:38 UTC #11 lore raw

Quoted 5 lines · Jan Kiszka

From: Jan Kiszka <[email protected]>
This is now implied by kvm_irqchip_in_kernel.
Signed-off-by Jan Kiszka <[email protected]>

Quoted 8 lines

---

Rebased over latest uq/master.

 kvm-all.c  |    6 ------
 kvm-stub.c |    6 ------
 kvm.h      |    2 --
 3 files changed, 0 insertions(+), 14 deletions(-)

Applied, thanks.