public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
* Handling vmentry failures in userspace
@ 2008-07-20 12:27 Mohammed Gamal
  2008-07-20 12:31 ` Avi Kivity
  0 siblings, 1 reply; 2+ messages in thread
From: Mohammed Gamal @ 2008-07-20 12:27 UTC (permalink / raw)
  To: Avi Kivity; +Cc: Anthony Liguori, kvm-devel, Rik van Riel, Guillaume Thouvenin

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?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Handling vmentry failures in userspace
  2008-07-20 12:27 Handling vmentry failures in userspace Mohammed Gamal
@ 2008-07-20 12:31 ` Avi Kivity
  0 siblings, 0 replies; 2+ messages in thread
From: Avi Kivity @ 2008-07-20 12:31 UTC (permalink / raw)
  To: Mohammed Gamal
  Cc: Anthony Liguori, kvm-devel, Rik van Riel, Guillaume Thouvenin

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-07-20 12:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-20 12:27 Handling vmentry failures in userspace Mohammed Gamal
2008-07-20 12:31 ` Avi Kivity

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox