| Message ID | 20110513081909.GA14603@elte.hu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 13, 2011 at 11:19 AM, Ingo Molnar <mingo@elte.hu> wrote: > @@ -162,7 +162,7 @@ static void kvm_register_mem_slot(struct kvm *kvm, u32 slot, u64 guest_phys, u64 > .slot = slot, > .guest_phys_addr = guest_phys, > .memory_size = size, > - .userspace_addr = (u64)userspace_addr, > + .userspace_addr = (u64)(long)userspace_addr, > }; Isn't + .userspace_addr = (unsigned long)userspace_addr, the right thing to do here? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Pekka Enberg <penberg@kernel.org> wrote: > On Fri, May 13, 2011 at 11:19 AM, Ingo Molnar <mingo@elte.hu> wrote: > > @@ -162,7 +162,7 @@ static void kvm_register_mem_slot(struct kvm *kvm, u32 slot, u64 guest_phys, u64 > > .slot = slot, > > .guest_phys_addr = guest_phys, > > .memory_size = size, > > - .userspace_addr = (u64)userspace_addr, > > + .userspace_addr = (u64)(long)userspace_addr, > > }; > > Isn't > > + .userspace_addr = (unsigned long)userspace_addr, > > the right thing to do here? Yeah, you are right - and userspace_addr will always be 32-bit on 32-bit hosts so this is unrelated to the guest-pfn conversion thing. More than 1-2 GB of RAM can be supported in the future by mmap()-ing a chunk, passing the address to KVM and then unmapping it. In theory it is possible to implement more than 4GB RAM support on 32-bit hosts without having to do highmem alike tricks in tools/kvm/, but i doubt there's much interest in that - everything is so much easier on 64-bit systems ... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2011-05-13 at 10:19 +0200, Ingo Molnar wrote: > FYI, the tools/kvm build still fails on 32-bit: > > cc1: warnings being treated as errors > qcow.c: In function ‘qcow1_write_sector’: > qcow.c:307: error: comparison between signed and unsigned integer expressions > make: *** [qcow.o] Error 1 > make: *** Waiting for unfinished jobs.... > > using: > > gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) > > The patch below addresses them but i haven't tested it beyond checking that it > builds. > > The double cast of userspace_addr is doubly sad - it highlights our 32-bitness > problems which are visible in the guest_pfn_to_host() function as well. KVM API uses 64-bit addresses no matter the host bitness, so we can't really get around doing these sort of casts.
* Sasha Levin <levinsasha928@gmail.com> wrote: > On Fri, 2011-05-13 at 10:19 +0200, Ingo Molnar wrote: > > FYI, the tools/kvm build still fails on 32-bit: > > > > cc1: warnings being treated as errors > > qcow.c: In function ‘qcow1_write_sector’: > > qcow.c:307: error: comparison between signed and unsigned integer expressions > > make: *** [qcow.o] Error 1 > > make: *** Waiting for unfinished jobs.... > > > > using: > > > > gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) > > > > The patch below addresses them but i haven't tested it beyond checking that it > > builds. > > > > The double cast of userspace_addr is doubly sad - it highlights our 32-bitness > > problems which are visible in the guest_pfn_to_host() function as well. > > KVM API uses 64-bit addresses no matter the host bitness, so we can't > really get around doing these sort of casts. that bit is OK - the KVM ABI has to be for the largest bit width. Note that this kind of ABI compatibility allows (in theory) to run a 32-bit kvm binary on a 64-bit kernel, and still everything would work despite hypervisor user-space being 32-bit. So the cast to (unsigned long) is fine and clean. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c index c69fcc4..e3f9d02 100644 --- a/tools/kvm/kvm.c +++ b/tools/kvm/kvm.c @@ -162,7 +162,7 @@ static void kvm_register_mem_slot(struct kvm *kvm, u32 slot, u64 guest_phys, u64 .slot = slot, .guest_phys_addr = guest_phys, .memory_size = size, - .userspace_addr = (u64)userspace_addr, + .userspace_addr = (u64)(long)userspace_addr, }; ret = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION, &mem); diff --git a/tools/kvm/qcow.c b/tools/kvm/qcow.c index 8e1b70d..bb2345c 100644 --- a/tools/kvm/qcow.c +++ b/tools/kvm/qcow.c @@ -295,7 +295,7 @@ static int qcow1_write_sector(struct disk_image *disk, u64 sector, void *src, u3 { struct qcow *q = disk->priv; struct qcow_header *header = q->header; - ssize_t nr_written; + u32 nr_written; char *buf; u64 offset; ssize_t nr;
FYI, the tools/kvm build still fails on 32-bit: cc1: warnings being treated as errors qcow.c: In function ‘qcow1_write_sector’: qcow.c:307: error: comparison between signed and unsigned integer expressions make: *** [qcow.o] Error 1 make: *** Waiting for unfinished jobs.... using: gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) The patch below addresses them but i haven't tested it beyond checking that it builds. The double cast of userspace_addr is doubly sad - it highlights our 32-bitness problems which are visible in the guest_pfn_to_host() function as well. Thanks, Ingo --- Signed-off-by: Ingo Molnar <mingo@elte.hu> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html