[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG |
Date: |
Tue, 20 Apr 2010 23:11:21 +0300 |
On 4/20/10, Ian Molton <address@hidden> wrote:
> Jamie Lokier wrote:
>
> Hi :-)
>
> > Ian Molton wrote:
> >> One last and quite important point - where should the EGD protocol
> >> implementation go? really it needs to work as kind-of a line discipline,
> >> but AFAICT thats not supported? it would be a mistake to put rate
> >> limiting in the chardev layer and leave the EGD protocol implementation
> >> in the driver.
> >
> > What do the other hypervisors supporting virtio-rng do?
>
> Um. support it? Im not sure what you mean there.
>
> > Personally I'm failing to see why EGD support is needed in Qemu, as
> > none of the crypto services on my Linux machines seem to need it so
> > why should Qemu be special, but I acknowledge there might be some
> > obscure reason.
>
> I know seevral people who use egd based hardware on their hosts who want
> virtio-rng support in their guests - it avoids having to route the data
> via TCP or other long winded paths that are trivially vulverable to
> attack both on the host and from the guests userspace. The hwrng core is
> inherently very simple.
>
> >> TBH, for the sake of one very simple driver, and given that apparently
> >> no other users in qemu seem to want rate-limiting, *I( think that you
> >> are massively over-complicating matters right now. If more drivers need
> >> rate limiting, perhaps, but that doesnt seem to be the case.
> >
> > Rate limiting both networking and serial ports may be a handy little
> > option sometimes.
>
> Perhaps, but I'm not a big user of those systems and as such Im not
> really in a position to design a rate limiting algorithm thats going to
> be really appropriate without spending a lot of time I dont have looking
> at stuff I don't really care about.
>
> I don't mind implementing trivial rate/burst limiting in the chardev
> layer if thats whats wanted, but I have neither the time nor inclination
> to write a thesis on the subject :-)
>
> > Iirc, there are some guests which get confused when
> > data transfers are gazillions times faster than they expected, or
> > gazillions times more bursty in the case of networking.
>
> Realistically, that kind of limiting might be best off in the device
> drivers those systems use, which has more intimate knowledge of how the
> virtual hardware should behave. Without extensive testing I just couldnt
> answer that.
>
> >>> We already have a virtual serial port implementation designed for
> >>> exactly this kind of application.
> >> Except that it doesn't speak to the kernels virtio-rng implementation.
> >> And that interface is not going to change just because you don't like
> >> it. (Unless you'd like to rewrite the kernels hwrng core? feel free! I'm
> >> sure it'd be appreciated - but if not, then don't complain)
> >
> > Would it be much work to change the guest to use virtio-serial
> > instead? Would it fit the problem or does virtio-rng need more
> > metadata than just a bytestream?
>
> If anything virtio-rng uses *less* info than the virtio-serial driver
> (it has one stream, in one direction, only).
>
> But the kernel already has a virtio-rng driver and it already works in a
> particular way, which is already implemented in other hypervisors. I
> didn't write the kernel driver, it is pre-existing. I suppose we could
> ask the kernel devs if they'd like another virtio-based rng driver in
> addition to the one already in use? but that seems perverse.
>
> Why even bother with virtio at all if you're going to abstract
> everything away behind a serial port? we could just modify all the guest
> kernel virtio-block drivers to serialise all their metadata, then we
> could use serial ports for that too!
>
> Abstraction can be taken too far.
>
> All MHO but I'm standing by what I said. If I can get a reasonable
> consensus about rewriting the code so that we get all the features
> needed for an enterprise level solution, namely
>
> * Fault tolerance - socket reconnection support.
> * EGD protocol support - because its what the users of this code (not me
> as such, I don't actually use it at all myself) actually want
> * virtio-rng support - because anything else is stupid and would involve
> getting a second virtio-serial-rng driver into the kernel.
>
> Then great.
>
> IMHO, the socket reconnect patch and the SIZE parameter patch fix
> obvious flaws in qemu and should be applied now, unless someone can come
> up with a good reason why they shouldn't.
>
> We can carry on debating the actual virtio-rng driver if thats whats
> wanted, but I have stated my position. So far the only argument against
> is "well I wouldn't choose to do it that way", which is hardly concrete
> reasoning.
>
> Please, please, can we get out of the bikeshed?
I would not call the discussions bikeshedding but architecture design
steering and project leadership.
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, (continued)
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/01
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Paul Brook, 2010/04/01
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/02
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Paul Brook, 2010/04/03
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/13
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Paul Brook, 2010/04/13
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Paul Brook, 2010/04/13
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG,
Blue Swirl <=
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/20
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Gerd Hoffmann, 2010/04/21
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/21
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/21
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Gerd Hoffmann, 2010/04/21
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/22
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Jamie Lokier, 2010/04/22
- Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG, Ian Molton, 2010/04/23