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

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

[Divya Garg]

Hi Vitaly Kuznetsov !
I was working on hyperv flags and saw that we introduced new 
dependencies some
time back 
(https://sourcegraph.com/github.com/qemu/qemu/-/commit/c686193072a47032d83cb4e131dc49ae30f9e5d7?visible=1).
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 ?

Thankyou
Regards
Divya Garg

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

[Vitaly Kuznetsov]

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://sourcegraph.com/github.com/qemu/qemu/-/commit/c686193072a47032d83cb4e131dc49ae30f9e5d7?visible=1).
> 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?

-- 
Vitaly

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

[Divya Garg]

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

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

[Vitaly Kuznetsov]

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.

> 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.

-- 
Vitaly

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

[Divya Garg]

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