Re: [Qemu-devel] [PATCH 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic
On 12/04/22 8:46 pm, Vitaly Kuznetsov wrote: Divya Garg writes: On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote: Divya Garg 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=DwIBAg=s883GpUCOChKOHiocYtGcg=2QGHz-fTCVWImEBKe1ZcSe5t6UfasnhvdzD5DcixwOE=ln-t0rKlkFkOEKe97jJTLi2BoKK5E9lLMPHjPihl4kpdbvBStPeD0Ku9wTed7GPf=AtipQDs1Mi-0FQtb1AyvBpR34bpjp64troGF_nr_08E= ). 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
Re: [Qemu-devel] [PATCH 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic
Divya Garg writes: > On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote: >> Divya Garg 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=DwIBAg=s883GpUCOChKOHiocYtGcg=2QGHz-fTCVWImEBKe1ZcSe5t6UfasnhvdzD5DcixwOE=ln-t0rKlkFkOEKe97jJTLi2BoKK5E9lLMPHjPihl4kpdbvBStPeD0Ku9wTed7GPf=AtipQDs1Mi-0FQtb1AyvBpR34bpjp64troGF_nr_08E= >>> ). >>> 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
On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote: Divya Garg 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=DwIBAg=s883GpUCOChKOHiocYtGcg=2QGHz-fTCVWImEBKe1ZcSe5t6UfasnhvdzD5DcixwOE=ln-t0rKlkFkOEKe97jJTLi2BoKK5E9lLMPHjPihl4kpdbvBStPeD0Ku9wTed7GPf=AtipQDs1Mi-0FQtb1AyvBpR34bpjp64troGF_nr_08E= ). 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
Divya Garg 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
[Qemu-devel] [PATCH 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic
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
[Qemu-devel] [PATCH 6/8] i386/kvm: hv-stimer requires hv-time and hv-synic
Synthetic timers operate in hv-time time and Windows won't use these
without SynIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9edf76e473..524ee28e9c 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1186,6 +1186,12 @@ static int hyperv_handle_properties(CPUState *cs,
if (cpu->hyperv_evmcs && !cpu->hyperv_vapic) {
r |= hv_report_missing_dep(cpu, "hv-evmcs", "hv-vapic");
}
+if (cpu->hyperv_stimer && !cpu->hyperv_synic) {
+r |= hv_report_missing_dep(cpu, "hv-stimer", "hv-synic");
+}
+if (cpu->hyperv_stimer && !cpu->hyperv_time) {
+r |= hv_report_missing_dep(cpu, "hv-stimer", "hv-time");
+}
/* Not exposed by KVM but needed to make CPU hotplug in Windows work */
env->features[FEAT_HYPERV_EDX] |= HV_CPU_DYNAMIC_PARTITIONING_AVAILABLE;
--
2.20.1
