Patchwork [uq/master] kvm: Drop unused kvm_pit_in_kernel

login
register
mail settings
Submitter Jan Kiszka
Date March 21, 2012, 12:36 p.m.
Message ID <4F69CB66.8080903@siemens.com>
Download mbox | patch
Permalink /patch/147975/
State New
Headers show

Comments

Jan Kiszka - March 21, 2012, 12:36 p.m.
This is now implied by kvm_irqchip_in_kernel.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 kvm-all.c  |    6 ------
 kvm-stub.c |    6 ------
 kvm.h      |    2 --
 3 files changed, 0 insertions(+), 14 deletions(-)
Avi Kivity - March 21, 2012, 1:36 p.m.
On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> This is now implied by kvm_irqchip_in_kernel.
>
>

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

No huge loss, but unexpected.
Jan Kiszka - March 21, 2012, 1:39 p.m.
On 2012-03-21 14:36, Avi Kivity wrote:
> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
>> 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
Gleb Natapov - March 21, 2012, 1:41 p.m.
On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
> On 2012-03-21 14:36, Avi Kivity wrote:
> > On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> >> This is now implied by kvm_irqchip_in_kernel.
> >>
> >>
> > 
> > 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 - March 21, 2012, 1:49 p.m.
On 2012-03-21 14:41, Gleb Natapov wrote:
> On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
>> On 2012-03-21 14:36, Avi Kivity wrote:
>>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
>>>> This is now implied by kvm_irqchip_in_kernel.
>>>>
>>>>
>>>
>>> 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
Gleb Natapov - March 22, 2012, 7:18 a.m.
On Wed, Mar 21, 2012 at 02:49:09PM +0100, Jan Kiszka wrote:
> On 2012-03-21 14:41, Gleb Natapov wrote:
> > On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
> >> On 2012-03-21 14:36, Avi Kivity wrote:
> >>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> >>>> This is now implied by kvm_irqchip_in_kernel.
> >>>>
> >>>>
> >>>
> >>> 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
> 
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 - March 22, 2012, 12:41 p.m.
On 2012-03-22 08:18, Gleb Natapov wrote:
> On Wed, Mar 21, 2012 at 02:49:09PM +0100, Jan Kiszka wrote:
>> On 2012-03-21 14:41, Gleb Natapov wrote:
>>> On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
>>>> On 2012-03-21 14:36, Avi Kivity wrote:
>>>>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
>>>>>> This is now implied by kvm_irqchip_in_kernel.
>>>>>>
>>>>>>
>>>>>
>>>>> 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
>>
> 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
Gleb Natapov - March 22, 2012, 12:52 p.m.
On Thu, Mar 22, 2012 at 01:41:18PM +0100, Jan Kiszka wrote:
> On 2012-03-22 08:18, Gleb Natapov wrote:
> > On Wed, Mar 21, 2012 at 02:49:09PM +0100, Jan Kiszka wrote:
> >> On 2012-03-21 14:41, Gleb Natapov wrote:
> >>> On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
> >>>> On 2012-03-21 14:36, Avi Kivity wrote:
> >>>>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> >>>>>> This is now implied by kvm_irqchip_in_kernel.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> 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
> >>
> > 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 - March 22, 2012, 1:27 p.m.
On 2012-03-22 13:52, Gleb Natapov wrote:
> On Thu, Mar 22, 2012 at 01:41:18PM +0100, Jan Kiszka wrote:
>> On 2012-03-22 08:18, Gleb Natapov wrote:
>>> On Wed, Mar 21, 2012 at 02:49:09PM +0100, Jan Kiszka wrote:
>>>> On 2012-03-21 14:41, Gleb Natapov wrote:
>>>>> On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
>>>>>> On 2012-03-21 14:36, Avi Kivity wrote:
>>>>>>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
>>>>>>>> This is now implied by kvm_irqchip_in_kernel.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>
>>> 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
Gleb Natapov - March 27, 2012, 10:48 a.m.
On Thu, Mar 22, 2012 at 02:27:37PM +0100, Jan Kiszka wrote:
> On 2012-03-22 13:52, Gleb Natapov wrote:
> > On Thu, Mar 22, 2012 at 01:41:18PM +0100, Jan Kiszka wrote:
> >> On 2012-03-22 08:18, Gleb Natapov wrote:
> >>> On Wed, Mar 21, 2012 at 02:49:09PM +0100, Jan Kiszka wrote:
> >>>> On 2012-03-21 14:41, Gleb Natapov wrote:
> >>>>> On Wed, Mar 21, 2012 at 02:39:47PM +0100, Jan Kiszka wrote:
> >>>>>> On 2012-03-21 14:36, Avi Kivity wrote:
> >>>>>>> On 03/21/2012 02:36 PM, Jan Kiszka wrote:
> >>>>>>>> This is now implied by kvm_irqchip_in_kernel.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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
> >>>>
> >>> 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. ;)
> 
Unfortunately I do, no matter how hard I try to forget :)

> 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.

Patch

diff --git a/kvm-all.c b/kvm-all.c
index 21c7dd2..7f8c188 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -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;
diff --git a/kvm-stub.c b/kvm-stub.c
index 1f1c686..fab3ab1 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -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;
diff --git a/kvm.h b/kvm.h
index 8ef4476..128cc8f 100644
--- a/kvm.h
+++ b/kvm.h
@@ -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);