On Sun, Apr 15, 2018 at 12:26:44AM +0200, KarimAllah Ahmed wrote:
> Switch 'requests' to be explicitly 64-bit and update BUILD_BUG_ON check to
> use the size of "requests" instead of the hard-coded '32'.
>
> That gives us a bit more room again for arch-specific requests as we
> already ran out of space for x86 due to the hard-coded check.
>
> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Cc: Radim Krčmář <rkrcmar@xxxxxxxxxx>
> Cc: kvm@xxxxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> Signed-off-by: KarimAllah Ahmed <karahmed@xxxxxxxxx>
> ---
> include/linux/kvm_host.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 6930c63..fe4f46b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -129,7 +129,7 @@ static inline bool is_error_page(struct page *page)
> #define KVM_REQUEST_ARCH_BASE 8
>
> #define KVM_ARCH_REQ_FLAGS(nr, flags) ({ \
> - BUILD_BUG_ON((unsigned)(nr) >= 32 - KVM_REQUEST_ARCH_BASE); \
> + BUILD_BUG_ON((unsigned)(nr) >= (sizeof(((struct kvm_vcpu *)0)->requests) * 8) - KVM_REQUEST_ARCH_BASE); \
> (unsigned)(((nr) + KVM_REQUEST_ARCH_BASE) | (flags)); \
> })
> #define KVM_ARCH_REQ(nr) KVM_ARCH_REQ_FLAGS(nr, 0)
> @@ -223,7 +223,7 @@ struct kvm_vcpu {
> int vcpu_id;
> int srcu_idx;
> int mode;
> - unsigned long requests;
> + u64 requests;
The usual thing to do for bitmaps is something like:
#define KVM_REQUEST_NR (KVM_REQUEST_ARCH_BASE + KVM_REQUEST_ARCH_NR)
unsigned long requests[BITS_TO_LONGS(NR_KVM_REQUESTS)];
> unsigned long guest_debug;
>
> int pre_pcpu;
> @@ -1122,7 +1122,7 @@ static inline void kvm_make_request(int req, struct kvm_vcpu *vcpu)
> * caller. Paired with the smp_mb__after_atomic in kvm_check_request.
> */
> smp_wmb();
> - set_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> + set_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
... which wouldn't require a void cast to make the bit API functions
happy (as these expect a pointer to the first unsigned long in the
bitmap).
Thanks,
Mark.
