Mohammed Gamal wrote:
With the unpredictable behaviour of the current vmentry failure patch,
I think this is caused by external interrupts from the host, and since
this is hard to control I was thinking of handling vmentry failure in
userspace. The way I am thinking of doing it is that once a vmentry
fails because of an invalid guest state we delegate the emulation to
userspace, and then we'd rely on QEMU's CPU emulation to emulate
instructions until we return to VMX-friendly state.
I don't have a strong grasp of the details on how the kernel- and
user-space side interact, so I don't know if that'd really be
possible? If it is, is it plausible to do it this way, or is it better
to leave all handling within the kernel side?
Userspace emulation doesn't work. Some of the emulated devices are in
the kernel; getting smp right in userspace is hard; and most importantly
doing some of the cpu emulation in userspace means that the boundary
between the kernel and userspace is blurred, making it difficult to
write alternative userspaces.
Fixing the problems we have may be hard, but we need to do this right.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
