On 02/18/2013 09:54 AM, Doug Goldstein wrote:
> On Mon, Feb 18, 2013 at 7:22 AM, Laine Stump <laine@xxxxxxxxx> 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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list