[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87haswptgq.fsf@rustcorp.com.au>
Date: Wed, 25 Jul 2012 10:06:37 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: Sasha Levin <levinsasha928@...il.com>, dlaor@...hat.com
Cc: mst@...hat.com, penberg@...nel.org, asias.hejun@...il.com,
virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org, avi@...hat.com,
anthony@...emonkey.ws, wency@...fujitsu.com,
"Peter Maydell" <peter.maydell@...aro.org>,
"Amit Shah" <amit.shah@...hat.com>
Subject: Re: [RFC 0/2] virtio: provide a way for host to monitor critical events in the device
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.
Cheers,
Rusty.
--
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