On 17.06.2012 17:14, Avi Kivity wrote:
> On 06/17/2012 04:06 PM, Blue Swirl wrote:
>
>>> strtosz() is much too general. We could do it in vl.c without trouble.
>>> However, it takes away our ability to emulate a "640k should be enough
>>> for everyone" machine.
>>
>> Then how about current max of target page sizes: 8k? No machine should
>> want less than that.
>
> Okay by me, but I can hear the we-should-have-a-generic-mechanism crowd
> charging their megaphone batteries.
So, is there some bottom line in that? I think I'll put a (temp)
fix/workaround for the debian package to require memory size to be
a multiple of 8K, and to produce a warning if that requiriment hasn't
met.
Something like this:
diff --git a/vl.c b/vl.c
index 5d9fc55..db98a4a 100644
--- a/vl.c
+++ b/vl.c
@@ -2671,7 +2675,15 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, "qemu: ram size too large\n");
exit(1);
}
- ram_size = value;
+#define RAM_SIZE_GRANULARITY (8*1024)
+ ram_size = value / RAM_SIZE_GRANULARITY;
+ ram_size *= RAM_SIZE_GRANULARITY;
+ if (ram_size != value) {
+ fprintf(stderr,
+ "warning: requested memory size (%" PRIu64 " bytes) "
+ "truncated to %" PRIu64 " bytes\n",
+ value, (uint64_t)ram_size);
+ }
break;
}
case QEMU_OPTION_mempath:
With this patch, running
qemu-system-x86_64 -m 1.4g
produces the following:
warning: requested memory size (1503238553 bytes) truncated to 1503232000 bytes
Thanks,
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
