diff options
| author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2024-09-17 18:00:48 +0200 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2024-10-17 12:30:21 +0200 |
| commit | bbf3810f2c4f97bd7a1982d3e0ff0f00295b8169 (patch) | |
| tree | 7d47d69a0d6a11fe55ba9e7fe3949a4f7ca9f639 /scripts/nsis.py | |
| parent | b5151ace58ba1db6bdfeedf4c17336f7195ee849 (diff) | |
| download | qemu-bbf3810f2c4f97bd7a1982d3e0ff0f00295b8169.zip qemu-bbf3810f2c4f97bd7a1982d3e0ff0f00295b8169.tar.gz qemu-bbf3810f2c4f97bd7a1982d3e0ff0f00295b8169.tar.bz2 | |
target/i386: Fix conditional CONFIG_SYNDBG enablement
Putting HYPERV_FEAT_SYNDBG entry under "#ifdef CONFIG_SYNDBG" in
'kvm_hyperv_properties' array is wrong: as HYPERV_FEAT_SYNDBG is not
the highest feature number, the result is an empty (zeroed) entry in
the array (and not a skipped entry!). hyperv_feature_supported() is
designed to check that all CPUID bits are set but for a zeroed
feature in 'kvm_hyperv_properties' it returns 'true' so QEMU considers
HYPERV_FEAT_SYNDBG as always supported, regardless of whether KVM host
actually supports it.
To fix the issue, leave HYPERV_FEAT_SYNDBG's definition in
'kvm_hyperv_properties' array, there's nothing wrong in having it defined
even when 'CONFIG_SYNDBG' is not set. Instead, put "hv-syndbg" CPU property
under '#ifdef CONFIG_SYNDBG' to alter the existing behavior when the flag
is silently skipped in !CONFIG_SYNDBG builds.
Leave an 'assert' sentinel in hyperv_feature_supported() making sure there
are no 'holes' or improperly defined features in 'kvm_hyperv_properties'.
Fixes: d8701185f40c ("hw: hyperv: Initial commit for Synthetic Debugging device")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/20240917160051.2637594-2-vkuznets@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'scripts/nsis.py')
0 files changed, 0 insertions, 0 deletions