qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KQEMU Darwin port status?


From: Philip Boulain
Subject: Re: [Qemu-devel] KQEMU Darwin port status?
Date: Wed, 21 Mar 2007 16:07:23 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]