Eduardo Habkost <ehabk...@redhat.com> writes: >> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c >> index 9e211ac2ce..6bcb7dbc2c 100644 >> --- a/target/i386/cpu.c >> +++ b/target/i386/cpu.c >> @@ -6133,34 +6133,6 @@ static void x86_cpu_realizefn(DeviceState *dev, Error >> **errp) >> Error *local_err = NULL; >> static bool ht_warned; >> >> - /* Process Hyper-V enlightenments */ >> - x86_cpu_hyperv_realize(cpu); > > Vitaly, is this reordering going to affect the Hyper-V cleanup > work you are doing? It seems harmless and it makes sense to keep > the "realize" functions close together, but I'd like to confirm. >
Currently, x86_cpu_hyperv_realize() is designed to run before kvm_hyperv_expand_features() (and thus x86_cpu_expand_features()): x86_cpu_hyperv_realize() sets some default values to cpu->hyperv_vendor/hyperv_interface_id/hyperv_version_id... but in 'hv-passthrough' mode these are going to be overwritten by KVM's values. By changing the ordering, this patch changes the logic so QEMU's default values will always be used, even in 'hv-passthrough' mode. This is undesireable. I'd suggest we keep x86_cpu_hyperv_realize() call where it is now, I'll think about possible cleanup later (when both this patch and the rest of my cleanup lands). -- Vitaly
