Re: [PATCH 0/2 v3] kvm: notify host when guest panicked

[Eric Northup]

On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@xxxxxxxxxx> wrote:
> On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote:
>> On 03/14/2012 03:14 PM, Gleb Natapov wrote:
>> > On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote:
>> > > On 03/14/2012 01:11 PM, Wen Congyang wrote:
>> > > > >
>> > > > > I don't think we want to use the driver.  Instead, have a small piece of
>> > > > > code that resets the device and pushes out a string (the panic message?)
>> > > > > without any interrupts etc.
>> > > > >
>> > > > > It's still going to be less reliable than a hypercall, I agree.
>> > > >
>> > > > Do you still want to use complicated and less reliable way?
>> > >
>> > > Are you willing to try it out and see how complicated it really is?
>> > >
>> > > While it's more complicated, it's also more flexible.  You can
>> > > communicate the panic message, whether the guest is attempting a kdump
>> > > and its own recovery or whether it wants the host to do it, etc., you
>> > > can communicate less severe failures like oopses.
>> > >
>> > hypercall can take arguments to achieve the same.
>>
>> It has to be designed in advance; and every time we notice something's
>> missing we have to update the host kernel.
>>
>
> We and in the designed stage now. Not to late to design something flexible
> :) Panic hypercall can take GPA of a buffer where host puts panic info
> as a parameter.  This buffer can be read by QEMU and passed to management.

If a host kernel change is in the works, I think it might be cleanest
to have the host kernel export a new kind of VCPU exit for
unhandled-by-KVM hypercalls.  Then usermode can respond to the
hypercall as appropriate.  This would permit adding or changing future
hypercalls without host kernel changes.

"Guest panic" is almost the definition of not-a-fast-path, and so
what's the reason to handle it in the host kernel.

Punting the functionality to user-space isn't a magic bullet for
getting a good interface designed, but in my opinion it is a better
place to be doing this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/