Re: [Qemu-devel] [PATCH 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic

[Divya Garg <divya.garg@nutanix.com>]

On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote:
> Divya Garg <divya.garg@nutanix.com> writes:
>
>> Hi Vitaly Kuznetsov !
>> I was working on hyperv flags and saw that we introduced new
>> dependencies some
>> time back
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__sourcegraph.com_github.com_qemu_qemu_-2D_commit_c686193072a47032d83cb4e131dc49ae30f9e5d7-3Fvisible-3D1&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=2QGHz-fTCVWImEBKe1ZcSe5t6UfasnhvdzD5DcixwOE&m=ln-t0rKlkFkOEKe97jJTLi2BoKK5E9lLMPHjPihl4kpdbvBStPeD0Ku9wTed7GPf&s=AtipQDs1Mi-0FQtb1AyvBpR34bpjp64troGF_nr_08E&e= ).
>> After these changes, if we try to live migrate a vm from older qemu to newer
>> one having these changes, it fails showing dependency issue.
>>
>> I was wondering if this is the expected behaviour or if there is any work
>> around for handing it ? Or something needs to be done to ensure backward
>> compatibility ?
> Hi Divya,
>
> configurations with 'hv-stimer' and without 'hv-synic'/'hv-time' were
> always incorrect as Windows can't use the feature, that's why the
> dependencies were added. It is true that it doesn't seem to be possible
> to forward-migrate such VMs to newer QEMU versions. We could've tied
> these new dependencies to newer machine types I guess (so old machine
> types would not fail to start) but we didn't do that back in 4.1 and
> it's been awhile since... Not sure whether it would make much sense to
> introduce something for pre-4.1 machine types now.
>
> Out of curiosity, why do such "incorrect" configurations exist? Can you
> just update them to include missing flags on older QEMU so they migrate
> to newer ones without issues?
>
Hi Vitaly !

Thanks for the response. I understand that these were incorrect 
configurations
and should be corrected. Only issue is, we want to avoid power cycling those
VMs. But yeah I think, since the configurations were wrong we should 
update and
power cycle the VM.  Just for understanding purpose, is it possible to 
disable
the feature by throwing out some warning message and update libvirt to 
metigate
this change and handle live migration ?

Or maybe update libvirt to not to ask for this feature from qemu during live
migration and handle different configuration on source and destination 
host ?

Thanks
Regards
Divya