| Message ID | 4F69CB66.8080903@siemens.com |
|---|---|
| State | New |
| Headers | show |
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.
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
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.
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
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.
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
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.
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
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.
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);
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(-)