From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4LQ0-0004zp-SK for qemu-devel@nongnu.org; Tue, 20 Apr 2010 17:55:44 -0400 Received: from [140.186.70.92] (port=44482 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4LPz-0004z8-Aq for qemu-devel@nongnu.org; Tue, 20 Apr 2010 17:55:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4LPx-0002ec-IN for qemu-devel@nongnu.org; Tue, 20 Apr 2010 17:55:43 -0400 Received: from mail2.shareable.org ([80.68.89.115]:60184) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4LPx-0002eP-CZ for qemu-devel@nongnu.org; Tue, 20 Apr 2010 17:55:41 -0400 Date: Tue, 20 Apr 2010 22:55:38 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG Message-ID: <20100420215538.GO11723@shareable.org> References: <4BB2053C.6000701@collabora.co.uk> <201004031606.26893.paul@codesourcery.com> <4BC482A6.4040504@collabora.co.uk> <201004131632.25820.paul@codesourcery.com> <4BCDC51F.2030205@collabora.co.uk> <20100420161302.GA11723@shareable.org> <4BCE061B.2030506@collabora.co.uk> <20100420205654.GI11723@shareable.org> <4BCE1D3B.7000306@collabora.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCE1D3B.7000306@collabora.co.uk> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Molton Cc: Gerd Hoffmann , Paul Brook , qemu-devel@nongnu.org Ian Molton wrote: > I've merely implemented one solution in qemu that other hypervisors > *AND* the kernel already support, and that users want. I think that's a good reason to include virtio-rng support in some form. I suspect Paul's objection may have been due to an impression that virtio-rng was a new thing developed by you, or an obscure thing that nobody uses at the moment. But: Does it have many users at present? > virtio-serial > ------------- > * Impossible to interface with the kernels hwrng core and thus > useless for debugging it and related tools on the guest. That was my question earlier: Impossible? Seems like it should be easy. The kernel can bind its console to virtio-serial, so it should be able to bind its hwrng to another one > > If it's dumb enough to just trickle the entropy through, that would > > seem a very good match to virtio-serial - apart from the guests which > > already expect virtio-rng support. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Isn't that latter feature a good enough reason on its own? qemu supports > a LOT of obscure hardware already - so "its weird" is also NOT a good > reason against it. And its not even weird or unusual in this instance. I agree, if there are more than a few obscure guests depending on it already. However if it's only a handful and they can easily be upgraded to a newer kernel using something else, maybe it's not worth it. Your patches don't just add another device emulation. They're a bit more invasive than that. > If qemu is only to support one way of doing any given operation then we > should get rid of a LOT of other drivers - like most of the video > drivers for example, and IDE/SCSI/SATA - well, all guests should just > use virtio-block, right? Sometimes, when I notice the increasing number of bug reports that older guest OSes no longer work, I get the impression that's what KVM developers would prefer :-) For a certain class of users that's right. Some users (generally the "virtualization farm" variety) only need to run recent guests which support virtio. -- Jamie