qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG
Date: Tue, 20 Apr 2010 22:55:38 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]