12:10 a.m.
The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
newer to set the lost tick policy for the PIT. While the
-no-kvm-pit-reinjection option is depreacated, it is still supported at
least through 1.4, it is better to not lose the functionality.
---
src/qemu/qemu_capabilities.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 51fc9dc..af52bbf 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2284,6 +2284,7 @@ virQEMUCapsInitQMPBasic(virQEMUCapsPtr qemuCaps)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_USER_CONFIG);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NETDEV_BRIDGE);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_SECCOMP_SANDBOX);
+ virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
--
1.7.12.4
7:22 a.m.
On 02/18/2013 01:10 AM, Doug Goldstein wrote:
The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2
and
newer to set the lost tick policy for the PIT. While the
-no-kvm-pit-reinjection option is depreacated, it is still supported at
least through 1.4, it is better to not lose the functionality.
After 1.4 will adding it to a commandline result in an error, or will it
be ignored?
Also, will something else be replacing it, or is it just no longer
useful/necessary?
It would be a bit perturbing if an "implied" capability disappeared,
with no way to detect via QMP whether or not it was there.
---
src/qemu/qemu_capabilities.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 51fc9dc..af52bbf 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2284,6 +2284,7 @@ virQEMUCapsInitQMPBasic(virQEMUCapsPtr qemuCaps)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_USER_CONFIG);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NETDEV_BRIDGE);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_SECCOMP_SANDBOX);
+ virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
8:54 a.m.
On Mon, Feb 18, 2013 at 7:22 AM, Laine Stump <laine(a)laine.org> wrote:
On 02/18/2013 01:10 AM, Doug Goldstein wrote:
> The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
> newer to set the lost tick policy for the PIT. While the
> -no-kvm-pit-reinjection option is depreacated, it is still supported at
> least through 1.4, it is better to not lose the functionality.
After 1.4 will adding it to a commandline result in an error, or will it
be ignored?
It still exists in qemu/master.
Also, will something else be replacing it, or is it just no longer
useful/necessary?
Yes. Patches coming to utilize -device
kvm-pit,lost-tick-policy=${valuehere} shortly. Which appeared at least
as early as 1.1
It would be a bit perturbing if an "implied" capability disappeared,
with no way to detect via QMP whether or not it was there.
The newer command line argument cannot be detected afaik right now
either. But its one of those things that always exists. I plan on
digging into it and more patches to come. But this patch came from the
fact that the functionality (which unfortunately a guest needs)
disappeared when I switched from qemu 1.1 to 1.2. Basically this was
an "oh crap get the feature back" patch.
> ---
> src/qemu/qemu_capabilities.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 51fc9dc..af52bbf 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -2284,6 +2284,7 @@ virQEMUCapsInitQMPBasic(virQEMUCapsPtr qemuCaps)
> virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_USER_CONFIG);
> virQEMUCapsSet(qemuCaps, QEMU_CAPS_NETDEV_BRIDGE);
> virQEMUCapsSet(qemuCaps, QEMU_CAPS_SECCOMP_SANDBOX);
> + virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
> }
>
>
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
Doug Goldstein
11:13 a.m.
On 02/18/2013 09:54 AM, Doug Goldstein wrote:
On Mon, Feb 18, 2013 at 7:22 AM, Laine Stump <laine(a)laine.org>
wrote:
> On 02/18/2013 01:10 AM, Doug Goldstein wrote:
>> The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
>> newer to set the lost tick policy for the PIT. While the
>> -no-kvm-pit-reinjection option is depreacated, it is still supported at
>> least through 1.4, it is better to not lose the functionality.
> After 1.4 will adding it to a commandline result in an error, or will it
> be ignored?
It still exists in qemu/master.
> Also, will something else be replacing it, or is it just no longer
> useful/necessary?
Yes. Patches coming to utilize -device
kvm-pit,lost-tick-policy=${valuehere} shortly. Which appeared at least
as early as 1.1
> It would be a bit perturbing if an "implied" capability disappeared,
> with no way to detect via QMP whether or not it was there.
The newer command line argument cannot be detected afaik right now
either. But its one of those things that always exists. I plan on
digging into it and more patches to come. But this patch came from the
fact that the functionality (which unfortunately a guest needs)
disappeared when I switched from qemu 1.1 to 1.2. Basically this was
an "oh crap get the feature back" patch.
Right.
So the story is this:
1) in older libvirt that doesn't use qmp capabilities detection we are
detecting presence of --no-kvm-pit-reinjection, and simply bypass it if
it's requested but doesn't exist.
2) with current libvirt that uses qmp, we currently assume
--no-kvm-pit-reinjection never exists, so silently don't add it to the
commandline when requested.
3) with this patch, we will assume that it always exists if we have a
qmp monitor. At least until 1.4, this is true.
4) You will be sending a patch that uses "a different method" of
achieving the same result, and that will be in place prior to any newer
version of qemu that may not have --no-kvm-pit-reinjection. That
alternative has existed since at least qemu 1.1.
Based on your promise of (4), ACK to this patch.
12:06 p.m.
On Mon, Feb 18, 2013 at 11:13 AM, Laine Stump <laine(a)laine.org> wrote:
On 02/18/2013 09:54 AM, Doug Goldstein wrote:
> On Mon, Feb 18, 2013 at 7:22 AM, Laine Stump <laine(a)laine.org> wrote:
>> On 02/18/2013 01:10 AM, Doug Goldstein wrote:
>>> The conversion to qemuCaps dropped the ability with qemu{,-kvm} 1.2 and
>>> newer to set the lost tick policy for the PIT. While the
>>> -no-kvm-pit-reinjection option is depreacated, it is still supported at
>>> least through 1.4, it is better to not lose the functionality.
>> After 1.4 will adding it to a commandline result in an error, or will it
>> be ignored?
> It still exists in qemu/master.
>
>> Also, will something else be replacing it, or is it just no longer
>> useful/necessary?
> Yes. Patches coming to utilize -device
> kvm-pit,lost-tick-policy=${valuehere} shortly. Which appeared at least
> as early as 1.1
>
>> It would be a bit perturbing if an "implied" capability disappeared,
>> with no way to detect via QMP whether or not it was there.
> The newer command line argument cannot be detected afaik right now
> either. But its one of those things that always exists. I plan on
> digging into it and more patches to come. But this patch came from the
> fact that the functionality (which unfortunately a guest needs)
> disappeared when I switched from qemu 1.1 to 1.2. Basically this was
> an "oh crap get the feature back" patch.
Right.
So the story is this:
1) in older libvirt that doesn't use qmp capabilities detection we are
detecting presence of --no-kvm-pit-reinjection, and simply bypass it if
it's requested but doesn't exist.
2) with current libvirt that uses qmp, we currently assume
--no-kvm-pit-reinjection never exists, so silently don't add it to the
commandline when requested.
3) with this patch, we will assume that it always exists if we have a
qmp monitor. At least until 1.4, this is true.
4) You will be sending a patch that uses "a different method" of
achieving the same result, and that will be in place prior to any newer
version of qemu that may not have --no-kvm-pit-reinjection. That
alternative has existed since at least qemu 1.1.
Based on your promise of (4), ACK to this patch.
Thanks. Pushed. Working on the patchset for this as we speak.
--
Doug Goldstein
4295
days inactive
4295
days old
4 comments
3 participants
participants (3)
-
Doug Goldstein -
Doug Goldstein -
Laine Stump