lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Mar 2012 11:47:33 -0700
From:	Eric Northup <digitaleric@...gle.com>
To:	Gleb Natapov <gleb@...hat.com>
Cc:	Avi Kivity <avi@...hat.com>, Wen Congyang <wency@...fujitsu.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	kvm list <kvm@...r.kernel.org>,
	qemu-devel <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Amit Shah <amit.shah@...hat.com>
Subject: Re: [PATCH 0/2 v3] kvm: notify host when guest panicked

On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ