target/i386/kvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
find_next_bit() takes a pointer of type "const unsigned long *", but the
first argument passed here is a "uint64_t *". These types are
incompatible when compiling qemu with -m32.
Just cast it to "const void *", find_next_bit() works fine with any type
on little-endian hosts (which x86 is).
Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d
Signed-off-by: Max Reitz <mreitz@redhat.com>
---
target/i386/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index e4b4f5756a..1b5f3b1c00 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1050,7 +1050,7 @@ static int hv_cpuid_check_and_set(CPUState *cs, struct kvm_cpuid2 *cpuid,
}
deps = kvm_hyperv_properties[feature].dependencies;
- while ((dep_feat = find_next_bit(&deps, 64, dep_feat)) < 64) {
+ while ((dep_feat = find_next_bit((const void *)&deps, 64, dep_feat)) < 64) {
if (!(hyperv_feat_enabled(cpu, dep_feat))) {
fprintf(stderr,
"Hyper-V %s requires Hyper-V %s\n",
--
2.21.0
On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote: > find_next_bit() takes a pointer of type "const unsigned long *", but the > first argument passed here is a "uint64_t *". These types are > incompatible when compiling qemu with -m32. > > Just cast it to "const void *", find_next_bit() works fine with any type > on little-endian hosts (which x86 is). > > Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d > Signed-off-by: Max Reitz <mreitz@redhat.com> Why not declare kvm_hyperv_properties.dependencies with the right type for bitmaps, using unsigned long dependencies[BITS_TO_LONGS(64)] ? > --- > target/i386/kvm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/i386/kvm.c b/target/i386/kvm.c > index e4b4f5756a..1b5f3b1c00 100644 > --- a/target/i386/kvm.c > +++ b/target/i386/kvm.c > @@ -1050,7 +1050,7 @@ static int hv_cpuid_check_and_set(CPUState *cs, struct kvm_cpuid2 *cpuid, > } > > deps = kvm_hyperv_properties[feature].dependencies; > - while ((dep_feat = find_next_bit(&deps, 64, dep_feat)) < 64) { > + while ((dep_feat = find_next_bit((const void *)&deps, 64, dep_feat)) < 64) { > if (!(hyperv_feat_enabled(cpu, dep_feat))) { > fprintf(stderr, > "Hyper-V %s requires Hyper-V %s\n", > -- > 2.21.0 > -- Eduardo
On 24.06.19 21:21, Eduardo Habkost wrote: > On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote: >> find_next_bit() takes a pointer of type "const unsigned long *", but the >> first argument passed here is a "uint64_t *". These types are >> incompatible when compiling qemu with -m32. >> >> Just cast it to "const void *", find_next_bit() works fine with any type >> on little-endian hosts (which x86 is). >> >> Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d >> Signed-off-by: Max Reitz <mreitz@redhat.com> > > Why not declare kvm_hyperv_properties.dependencies with the right > type for bitmaps, using > unsigned long dependencies[BITS_TO_LONGS(64)] > ? How would you (statically) initialize that field, then? I cannot imagine a reasonable static way that does not invoke the same “The host must be little-endian, so it’s OK” assumption. The better question is perhaps, why not use ffsll(). Hm. I don’t know, maybe I should? Max
On 24.06.19 21:26, Max Reitz wrote: > On 24.06.19 21:21, Eduardo Habkost wrote: >> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote: >>> find_next_bit() takes a pointer of type "const unsigned long *", but the >>> first argument passed here is a "uint64_t *". These types are >>> incompatible when compiling qemu with -m32. >>> >>> Just cast it to "const void *", find_next_bit() works fine with any type >>> on little-endian hosts (which x86 is). >>> >>> Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d >>> Signed-off-by: Max Reitz <mreitz@redhat.com> >> >> Why not declare kvm_hyperv_properties.dependencies with the right >> type for bitmaps, using >> unsigned long dependencies[BITS_TO_LONGS(64)] >> ? > > How would you (statically) initialize that field, then? > > I cannot imagine a reasonable static way that does not invoke the same > “The host must be little-endian, so it’s OK” assumption. Sorry, brain fart. That’s not the problem because in either case, the lower index will receive the lower-indexed bits. But we’d still have to deal with the fact that it could either be one or two indices, which doesn’t seem nice to initialize either. Max > The better question is perhaps, why not use ffsll(). Hm. I don’t know, > maybe I should? > > Max >
On Mon, Jun 24, 2019 at 09:30:26PM +0200, Max Reitz wrote: > On 24.06.19 21:26, Max Reitz wrote: > > On 24.06.19 21:21, Eduardo Habkost wrote: > >> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote: > >>> find_next_bit() takes a pointer of type "const unsigned long *", but the > >>> first argument passed here is a "uint64_t *". These types are > >>> incompatible when compiling qemu with -m32. > >>> > >>> Just cast it to "const void *", find_next_bit() works fine with any type > >>> on little-endian hosts (which x86 is). > >>> > >>> Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d > >>> Signed-off-by: Max Reitz <mreitz@redhat.com> > >> > >> Why not declare kvm_hyperv_properties.dependencies with the right > >> type for bitmaps, using > >> unsigned long dependencies[BITS_TO_LONGS(64)] > >> ? > > > > How would you (statically) initialize that field, then? > > > > I cannot imagine a reasonable static way that does not invoke the same > > “The host must be little-endian, so it’s OK” assumption. > > Sorry, brain fart. That’s not the problem because in either case, the > lower index will receive the lower-indexed bits. > > But we’d still have to deal with the fact that it could either be one or > two indices, which doesn’t seem nice to initialize either. Right, a uint64_t field is more convenient to initialize. > > Max > > > The better question is perhaps, why not use ffsll(). Hm. I don’t know, > > maybe I should? uint64_t + ffsll() seems simple and appropriate. -- Eduardo
© 2016 - 2024 Red Hat, Inc.