Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On Thu, Jan 19, 2012 at 07:01:44PM +0100, Jan Kiszka wrote: On 2012-01-19 18:53, Marcelo Tosatti wrote: What problems does it cause, and in which scenarios? Can't they be fixed? If the guest compensates for lost ticks, and KVM reinjects them, guest time advances faster then it should, to the extent where NTP fails to correct it. This is the case with RHEL4. But for example v2.4 kernel (or Windows with non-acpi HAL) do not compensate. In that case you want KVM to reinject. I don't know of any other way to fix this. OK, i see. The old unsolved problem of guessing what is being executed. Then the next question is how and where to control this. Conceptually, there should rather be a global switch say compensate for lost ticks of periodic timers: yes/no - instead of a per-timer knob. Didn't we discussed something like this before? I don't see the advantage of a global control versus per device control (in fact it lowers flexibility). What about periodic APIC tick compensation? I suppose the kernel does not support this as no common guest makes use of this as clock source, right? Recent guests use the APIC timer as clock event, but their time keeping algorithms are not as susceptible to lost ticks as the ones that use PIT/RTC. Or the HPET? Once the user space model supports compensation, we need to control it as well. Individually? Ulrich has posted patches for HPET compensation: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01989.html I just want to avoid introducing an clumsy interface we then need to maintain for a long time. Jan If the option is a qdev property, i don't see what is clumsy about it? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On 2012-01-20 11:14, Marcelo Tosatti wrote: On Thu, Jan 19, 2012 at 07:01:44PM +0100, Jan Kiszka wrote: On 2012-01-19 18:53, Marcelo Tosatti wrote: What problems does it cause, and in which scenarios? Can't they be fixed? If the guest compensates for lost ticks, and KVM reinjects them, guest time advances faster then it should, to the extent where NTP fails to correct it. This is the case with RHEL4. But for example v2.4 kernel (or Windows with non-acpi HAL) do not compensate. In that case you want KVM to reinject. I don't know of any other way to fix this. OK, i see. The old unsolved problem of guessing what is being executed. Then the next question is how and where to control this. Conceptually, there should rather be a global switch say compensate for lost ticks of periodic timers: yes/no - instead of a per-timer knob. Didn't we discussed something like this before? I don't see the advantage of a global control versus per device control (in fact it lowers flexibility). Usability. Users should not have to care about individual tick-based clocks. They care about my OS requires lost ticks compensation, yes or no. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote:
Hi all,
I've finished a first version of cleaned-up in-kernel KVM PIT support.
That will be rolled out once the base support for irqchip has been merged.
I'm now wondering if and how to model two control knobs we have in qemu-kvm:
o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC
are kernel based (default: off, ie. use in-kernel PIT)
It can be useful for debugging.
o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection
logic in the kernel (default: off, ie. do reinject)
If the guest kernel does not compensate for lost ticks, reinjection is
needed. Otherwise, it might cause problems.
Therefore this option is needed.
So far I dropped the former and modeled the latter via a qdev property.
But I tend to think that even the latter knob is superfluous. In that
case I would also deprecate the original switches in qemu-kvm, just like
recently done with -tdf.
Other thoughts?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On 2012-01-19 18:25, Marcelo Tosatti wrote:
On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote:
Hi all,
I've finished a first version of cleaned-up in-kernel KVM PIT support.
That will be rolled out once the base support for irqchip has been merged.
I'm now wondering if and how to model two control knobs we have in qemu-kvm:
o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC
are kernel based (default: off, ie. use in-kernel PIT)
It can be useful for debugging.
When was it last? The kernel model should be stable by now, just
possibly incomplete. But then there is still the full emulation in user
mode, available via kernel_irqchip=off.
We can control it, the question is if we really need the granularity.
o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection
logic in the kernel (default: off, ie. do reinject)
If the guest kernel does not compensate for lost ticks, reinjection is
needed. Otherwise, it might cause problems.
That's why it's /on/ by default? What problems does it cause, and in
which scenarios? Can't they be fixed?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On Thu, Jan 19, 2012 at 06:38:01PM +0100, Jan Kiszka wrote:
On 2012-01-19 18:25, Marcelo Tosatti wrote:
On Thu, Jan 19, 2012 at 09:33:51AM +0100, Jan Kiszka wrote:
Hi all,
I've finished a first version of cleaned-up in-kernel KVM PIT support.
That will be rolled out once the base support for irqchip has been merged.
I'm now wondering if and how to model two control knobs we have in
qemu-kvm:
o -no-kvm-pit, ie. disable the in-kernel PIT even when {A,IOA,}PIC
are kernel based (default: off, ie. use in-kernel PIT)
It can be useful for debugging.
When was it last? The kernel model should be stable by now, just
possibly incomplete. But then there is still the full emulation in user
mode, available via kernel_irqchip=off.
We can control it, the question is if we really need the granularity.
Right, that should be enough.
o -no-kvm-pit-reinjection, ie. control over the lost ticks reinjection
logic in the kernel (default: off, ie. do reinject)
If the guest kernel does not compensate for lost ticks, reinjection is
needed. Otherwise, it might cause problems.
That's why it's /on/ by default?
Its on by default because it was the default before the option
was introduced.
What problems does it cause, and in which scenarios? Can't they be
fixed?
If the guest compensates for lost ticks, and KVM reinjects them, guest
time advances faster then it should, to the extent where NTP fails to
correct it. This is the case with RHEL4.
But for example v2.4 kernel (or Windows with non-acpi HAL) do not
compensate. In that case you want KVM to reinject.
I don't know of any other way to fix this.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?
On 2012-01-19 18:53, Marcelo Tosatti wrote: What problems does it cause, and in which scenarios? Can't they be fixed? If the guest compensates for lost ticks, and KVM reinjects them, guest time advances faster then it should, to the extent where NTP fails to correct it. This is the case with RHEL4. But for example v2.4 kernel (or Windows with non-acpi HAL) do not compensate. In that case you want KVM to reinject. I don't know of any other way to fix this. OK, i see. The old unsolved problem of guessing what is being executed. Then the next question is how and where to control this. Conceptually, there should rather be a global switch say compensate for lost ticks of periodic timers: yes/no - instead of a per-timer knob. Didn't we discussed something like this before? What about periodic APIC tick compensation? I suppose the kernel does not support this as no common guest makes use of this as clock source, right? Or the HPET? Once the user space model supports compensation, we need to control it as well. Individually? I just want to avoid introducing an clumsy interface we then need to maintain for a long time. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
