Re: [PATCHv2] KVM: inject #UD if instruction emulation fails and exit to userspace

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

(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@redhat.com>  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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html