(2010/05/11 2:33), Gleb Natapov wrote:
On Mon, May 10, 2010 at 07:06:05PM +0300, Mohammed Gamal wrote:
On Mon, May 10, 2010 at 1:25 PM, Gleb Natapov<gleb@xxxxxxxxxx> wrote:
On Mon, May 10, 2010 at 11:16:56AM +0300, Gleb Natapov wrote:
Do not kill VM when instruction emulation fails. Inject #UD and report
failure to userspace instead. Userspace may choose to reenter guest if
vcpu is in userspace (cpl == 3) in which case guest OS will kill
offending process and continue running.
I am curious to know what'd happen in case the vcpu is in kernel space
(cpl == 0). Is that case handled?
Currently no matter where emulation fails VM is stopped and cpu state is
printed on stderr. After that patch userspace may choose to continue VM
execution after emulation error (#UD will be injected into VM though). The
policy is in userspace, but I don't see the point to continue execution
after emulation failed in kernel. How kernel can recover from the #UD?
I don't see what is the recommended(possible) way of trouble shooting yet.
If the user is managing both the guest and the host, it's simple: no worth
reentering the guest. The user will just see the stderr.
But what about if the user can only see the guest?
In the case of non-virt, usually the user sees oops log or something and calls
to a support staff. Compared to that, if VM is silently stopped, what information
can the user see? In such a case, catching up the trouble and calling to a support
staff is host side management staff's job?
If you give us preferred way of trouble shooting of KVM, from the developer's point
of view, it will really help us to prepare for the future use of KVM.
What we can do will depend on your development!
And this is one of the reasons why I'm interested in the x86's emulation
development. :-)
Thanks,
Takuya
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
