[libvirt] [PATCH] qemu: Only issue the rtc-reset-reinjection QMP command on x86.

Martin Kletzander mkletzan at redhat.com
Tue May 26 08:53:53 UTC 2015


On Tue, May 26, 2015 at 10:08:58AM +0200, Peter Krempa wrote:
>On Mon, May 25, 2015 at 17:43:05 +0200, Martin Kletzander wrote:
>> On Mon, May 25, 2015 at 05:26:01PM +0200, Peter Krempa wrote:
>> >On Mon, May 25, 2015 at 16:59:08 +0200, Andrea Bolognani wrote:
>> >> The command is only defined in QEMU for TARGET_I386, so issuing it on
>> >> any other architecture can't possibly work.
>> >>
>> >> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1211938
>> >> ---
>> >>  src/qemu/qemu_driver.c | 20 +++++++++++++-------
>> >>  1 file changed, 13 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> >> index aa0acde..743ca6e 100644
>> >> --- a/src/qemu/qemu_driver.c
>> >> +++ b/src/qemu/qemu_driver.c
>> >> @@ -18945,7 +18945,10 @@ qemuDomainSetTime(virDomainPtr dom,
>> >>          goto endjob;
>> >>      }
>> >>
>> >> -    if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_RTC_RESET_REINJECTION)) {
>> >> +    /* The rtc-reset-reinjection QMP command is only available on x86 */
>> >
>> >Since we properly track support for this command via the capabilities
>> >and qemu does not expose it:
>> >
>> >> +    if (ARCH_IS_X86(vm->def->os.arch) &&
>> >> +        !virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_RTC_RESET_REINJECTION))
>> >> +    {
>> >>          virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
>> >>                         _("cannot set time: qemu doesn't support "
>> >>                           "rtc-reset-reinjection command"));
>> >
>> >I'd simply remove this error message since it is semantically wrong once
>> >PPC does not require to reset the RTC reinjection.
>> >
>> >> @@ -18968,13 +18971,16 @@ qemuDomainSetTime(virDomainPtr dom,
>> >>          goto endjob;
>> >>      }
>> >>
>> >> -    qemuDomainObjEnterMonitor(driver, vm);
>> >> -    rv = qemuMonitorRTCResetReinjection(priv->mon);
>> >> -    if (qemuDomainObjExitMonitor(driver, vm) < 0)
>> >> -        goto endjob;
>> >> +    /* The rtc-reset-reinjection QMP command is only available on x86 */
>> >> +    if (ARCH_IS_X86(vm->def->os.arch)) {
>> >> +        qemuDomainObjEnterMonitor(driver, vm);
>> >> +        rv = qemuMonitorRTCResetReinjection(priv->mon);
>> >
>> >And just conditionally call this when the
>> >QEMU_CAPS_RTC_RESET_REINJECTION is present and not in an architecture
>> >specific way.
>> >
>> >By this you get rid of the arch specific hackery.
>> >
>>
>> But on x86 we don't even want to call the SetTime command when we
>> cannot reset the rtc reinjection.  On ppc there is no reinjection
>> being done, hence nothing to reset.
>
>Well I don't think that the missing reinjection request should be a hard
>requirement on x86 since the guest can modify time independently and in
>that case the reinjection command won't be even issued. The guest agent
>command is technically a guest issued time change too, so there's only
>the added bonus that we'd reset the interrupt backlog. One slight issue
>is that libvirt does not allow to reset the interrupt backlog while not
>setting the time though.
>

The implementer of the check might remember more reasons for arguing
on this, let him shed the light into this discussion.  Michal?

Anyway, this is broken all the way because the command also makes
sense only with some particular timers and their settins, not with all
of them.

>Even if we decide that the check for the existance of the command should
>be arch-specific and should report error, the actual place where the
>command is called should be made dependant on the presence of the
>command rather than the ARCH check, so that it does not need to be
>modified once it's implemented somewhere else.
>

I don't quite catch your drift here.  If you mean that the second
condition added should be based on virQEMUCapsGet(), then I agree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150526/4201f814/attachment-0001.sig>


More information about the libvir-list mailing list