Aww..crap.
Please disregard.. I was running under 'vdeq', and it looks like vdeq is
eating the '-m' argument for itself iff it's the first argument on the
qemu command line.
As you can see, when running under vdeq (and some extra debugging
printf's added):
$ sudo vdeq ./qemu-system-x86_64 -m 512 test.img
ram_size=134217728
phys_ram_size=146812928
$ sudo vdeq ./qemu-system-x86_64 test.img -m 512
ram_size=536870912
phys_ram_size=549466112
Without vdeq, everything runs fine. Sorry for the noise...
john.c
On Sun, 2007-11-11 at 00:30 +0200, Dan Kenigsberg wrote:
> On Sat, Nov 10, 2007 at 01:22:06PM -0500, John Clemens wrote:
> > It appears the qemu in KVM-51 has a weird glitch where it will ignore
> > the '-m' memory parameter if it's the first parameter on the command
> > line (the case 'QEMU_OPTION_m' stanza never gets called in
> > qemu/hw/vl.c:main()). A quick look at the code doesn't reveal anything
> > obvious to me as to why. Putting some other parameter first (like
> > '-hda') works just fine. This doesn't happen with the current qemu
> > cvs.
> >
> > i.e.:
> >
> > qemu-system-x86_64 -m 512 -hda test.img == 128MB ram in VM.
> > qemu-system-x86_64 -hda test.img -m 512 == 512MB ram in VM.
> >
>
> I failed to reproduce this on my system (but I could not try if with the
> exact same params). What's your host? What happens when you pass an
> absurdly large memory size?
>
> I get
> $ ./qemu-system-x86_64 -m 4000 -hda /images/fc6.img
> kvm_alloc_userspace_memory: Cannot allocate memoryCould not create KVM context
>
> Dan.
|
