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 8:46 pm, Vitaly Kuznetsov wrote:
> Divya Garg <divya.garg@nutanix.com> writes:
>
>> 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 ?
>>
> I'm not exactly sure about libvirt, I was under the impression it makes
> sure that QEMU command line is the same on the destination and on the
> source. If there's a way to add something, I'd suggest you add the
> missing features (hv-time, hv-synic) on the destination rather than
> remove 'hv-stimer' as it is probably safer.
Yes libvirt makes sure that the configurations remains constant on 
source and
destination. And true that adding new features is a safer route.
>
>> 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 ?
> You can also modify QEMU locally and throw away these dependencies,
> it'll allow these configurations again but generally speaking checking
> that the set of hyper-v features is exactly the same on the source and
> destination is the right thing to do: there are no guarantees that guest
> OS (Windows) will keep behaving sane when the corresponding CPUIDs
> change while it's running, all sorts of things are possible I believe.
True that. Its really difficult to predict the change in behaviour of 
guest on
changing CPUIDs especially disabling a bit. I agree best solution will be to
power cycle the VMs and update the correct CPUIDs maintaining correct
dependency. Thankyou for clearing out the doubts and helping in a better
understanding.

Regards
Divya