linux-kernel - Re: [PATCH 0/5 V5] Avoid soft lockup message when KVM is stopped by host

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Dec 2011 07:31:49 -0200
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Eric B Munson <emunson@...bm.net>, mingo@...hat.com, hpa@...or.com,
	arnd@...db.de, ryanh@...ux.vnet.ibm.com, aliguori@...ibm.com,
	jeremy.fitzhardinge@...rix.com, levinsasha928@...il.com,
	Jan Kiszka <jan.kiszka@...mens.com>, kvm@...r.kernel.org,
	linux-arch@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5 V5] Avoid soft lockup message when KVM is stopped by
 host

On Thu, Dec 15, 2011 at 12:21:16PM +0200, Avi Kivity wrote:
> On 12/14/2011 08:21 PM, Marcelo Tosatti wrote:
> > On Wed, Dec 14, 2011 at 04:39:56PM +0200, Avi Kivity wrote:
> > > On 12/14/2011 02:16 PM, Marcelo Tosatti wrote:
> > > > > Having this controlled from userspace means it doesn't work for SIGSTOP
> > > > > or for long scheduling delays.  What about doing this automatically
> > > > > based on preempt notifiers?
> > > >
> > > > Long scheduling delays should be considered hangups from the guest
> > > > perspective.
> > > 
> > > Why?  To the guest it looks like slow hardware, but it will interpret it
> > > as a softlockup.
> >
> > Slow enough that progress of the watchdog thread is unable to keep up
> > with timer interrupt processing. This is considered a hang and
> > should be reported.
> 
> It's not a guest hang though!

No, but your host system is in such a load state that for the sake of
system usability you better print out a warning message.

I don't see the advantage of preempt notifiers over the simple, paravirt
solution proposed? Note kvmclock is already paravirt.

What do you want to be done in preempt notifiers? Measure what to
consider setting this flag?

--
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/