On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov
<address@hidden> 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 to user-space wouldn't be a magic bullet for getting good interfaces designed, but in my opinion it is a better place to be doing them.