On 21 Mar 2007, at 15:39, Derek Fawcus wrote:
Well, they seemed to be suggesting that the kernel importing and
locking
the user space memory was a bit dodgy, and that the kernel should
export
memory to user space. Or maybe that only really applies in the
case of
devices...
Yes. It's perfectly valid to point out that this is usually a bad
thing to do, but to refuse to help on those grounds is---well,
unhelpful. Sometimes, you have no choice but to do something which is
normally bizzare. (What I /don't/ get is why Bhavesh didn't explain
the 'bizzare' circumstances, given that that thread appears to be
post-GPL-KQEMU.)
I can see why this appears to be a bad thing, but it's also how KQEMU
works, and I'm guessing that /that/ is for good reasons, even if
they're good reasons on some other platform it supports. (One that
comes to mind is that you /probably/ don't want to ask for 4GB of
kernel-allocated memory in order to run a VM with 4GB of RAM.)
AFAICT, the worst /effect/ of this is that a userland application
could cause the kernel to either wire down so much memory that it
can't swap things in, or run out of kernel address space, and I would
expect those risks to affect other platforms too---in other words,
you could probably crash the system from a userland application with
access to the /dev/kqemu device. I /don't/ see any reason why it
should be "dodgy" in the unpleasant-to-debug--side-effects sense;
hopefully because no such reason exists. :)
Phil
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
