linux-kernel - Re: [RFC 0/2] virtio: provide a way for host to monitor critical events in the device

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] [day] [month] [year] [list]

Date:	Wed, 25 Jul 2012 14:16:28 +0530
From:	Amit Shah <amit.shah@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Sasha Levin <levinsasha928@...il.com>, dlaor@...hat.com,
	Peter Maydell <peter.maydell@...aro.org>, wency@...fujitsu.com,
	kvm@...r.kernel.org, mst@...hat.com, linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, penberg@...nel.org,
	avi@...hat.com, anthony@...emonkey.ws
Subject: Re: [RFC 0/2] virtio: provide a way for host to monitor critical
 events in the device

On (Wed) 25 Jul 2012 [10:06:37], Rusty Russell wrote:
> On Tue, 24 Jul 2012 15:01:59 +0200, Sasha Levin <levinsasha928@...il.com> wrote:
> > virtio on it's own was introduced to help solve the fragmentation
> > around virtualized devices, so I don't think that the main purpose of
> > doing virtio drivers is due to any performance benefits virtio may
> > provide.
> 
> There's one argument in your favor (with my Linaro hat on): ARM wants a
> virtio reboot button, which would look remarkably similar.  There's no
> standard ARM hardware for this.
> 
> So a more generalized virtio-event device might make sense.  But there
> are almost an infinite number of guest events we might want: panics,
> oom, low memory, stuck devices, deadlock, etc, etc.  I'm concerned about
> trying to standardize them.  If we include a unspecified free-form
> string, people will end up relying on the contents.  If we add a feature
> bit for every new event, we'll end up running out of feature bits :)
> 
> CC'ing Amit for opinion over how much of this should be done via
> virtio-serial.

The prevoius discussion happend on kvm-devel; it was suggested then to
use virtio-serial for that as well.  We don't have an in-kernel
interface for communication yet (barring the console interface, which
we don't want to re-use for other reasons).

Writing the in-kernel interface for communication with the host is not
too much work as well.

I agree using virtio-serial for several such free-form message-passing
between the guest and host is the right way to implement such stuff.

The lack of dedicated devices over either virtio or emulation of
real hardware can be overcome by adding some documentation -
preferably to the virtio spec's appendix, showing how watchdogs, etc.,
are implemented using virtio-serial.

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