From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5bVF-0006jL-DD for qemu-devel@nongnu.org; Sat, 24 Apr 2010 05:18:21 -0400 Received: from [140.186.70.92] (port=52496 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5bVC-0006jA-FL for qemu-devel@nongnu.org; Sat, 24 Apr 2010 05:18:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5bV9-0003qg-Sn for qemu-devel@nongnu.org; Sat, 24 Apr 2010 05:18:18 -0400 Received: from bhuna.collabora.co.uk ([93.93.128.226]:47931) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5bV9-0003qV-KO for qemu-devel@nongnu.org; Sat, 24 Apr 2010 05:18:15 -0400 Message-ID: <4BD2B709.5070302@collabora.co.uk> Date: Sat, 24 Apr 2010 10:16:57 +0100 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG References: <4BCE1D3B.7000306@collabora.co.uk> <4BCEAC99.8000206@redhat.com> <20100421094007.GC13114@shareable.org> <4BCEF0B9.2050704@collabora.co.uk> <4BCF03D2.5000307@redhat.com> <4BD09E3F.7070605@collabora.co.uk> <4BD15A0D.6090801@redhat.com> <4BD16845.9090001@collabora.co.uk> <4BD1A998.2020500@redhat.com> <4BD1C184.9030300@collabora.co.uk> <20100423173252.GB15349@shareable.org> In-Reply-To: <20100423173252.GB15349@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, Gerd Hoffmann , Paul Brook On 23/04/10 18:32, Jamie Lokier wrote: > Ian Molton wrote: >>> You can configure any chardev to be a tcp client. I never do that though >>> as I find it much more convenient to configure it as server. >> >> Perhaps thats because chardev clients are nearly useless right now >> because they just die if the connection drops... > > Which is why drops/missing server should be a QMP event + action, same > as other triggers like disk full and watchdog trigger. So write the code then. I neither want nor care about that feature, so why should I write it? > I do not want my guests to continue running if they are configured to > depend on Qemu entropy and it's not available. Realistically though, causes of EGD dissapearing... 1) the daemon dies 2) the daemon is replaced in the case of 1) then potentially the host, and *every single* guest will run out of entropy. You only need one flashing red light, and the host can tell you that as well as any of the guests. Entropy starvation doesnt usually lead to the catastrophic failure you describe - 99.9999% of linux machines have no entropy source configured and they get along just fine - even with process address space randomisation enabled. In the case of 2) then the downtime is so short that a warning would be inappropriate, and the sysadmin would be *right there* anyway. >> Or are you suggesting that we create another type of chardev, thats >> nearly like a socket, but speaks egd and can reconnect? That seems >> hideous to me. > > Why hideous? Because automatic reconection should not apply to only one type of socket, but all. Why deliberately cripple a feature and make it specific when one does not have to? > An egd chardev is a good thing because you can then trivially > use it as a random byte source for virtio-serial, isa-serial, > pci-serial, custom-soc-serial, debug-port even :-), and anything > else which might want random bytes as Gerd said. Yes, but qemu (AFAICT) does not support "line disciplines" so we can either have chrdev_egd+reconnect -> virtio-* backend or chrdev_socket+reconnect -> virtio-rng+egd backend IOW, we can either have generic reconnect support, or generic egd support, but not both. Ideally, we'd have line disciplines and it'd be more like this: chrdev_socket+reconnect -> egd ldisc -> virtio-* backend So, given that we dont have line disciplines (and I'm not about to write more code that is just going to get squabbled over for months) that leaves us with a choice to make. I personally say that generic EGD support is less useful than generic socket reconnect support, since at a pinch, and as others have pointed out, EGD can be implemented externally to qemu. Socket reconnection _cannot_ be implemented externally, and frankly, I consider it a bug that qemu basically presents an option (client sockets) that once it dies, the user has no way of re-instating other than to kill and restart qemu. > That's way more useful than restricting to virtio-rng, because most > guests don't support virtio at all, but they can probably all take > entropy from a serial-like device. a) The kind of guest that cant do virtio is damn unlikely to be in use in a server-farm, and b) Nothing stops someone running an egd->serial converter on the host in order to feed a serial-like device. > Similarly the ability to connect to /dev/urandom directly, with the > rate-limiting but no auto-reconnection, looking like a chardev in > the same way, would make sense. Reconnection is not needed in this > case - missing device should be an error at startup. My current code will happily read entropy from a file, a char device or a socket. It can *also* speak EGD on bidirectional connections like sockets. > Your idea for an 'egd line discipline' would need to look exactly like > a chardev internally Well of course it would. Thats what line disciplines are supposed to do. (look at their analogue in the linux tty code) > In which case it's quite natural to expose the options as a > user-visible chardev 'egd', defined to return random bytes on input > and ignore output, which takes all the same options as 'socket' and > actually uses a 'socket' chardev (passing along the options). Unless I'm missing something, qemu cannot chain multiple chrdevs together. Which means that the hypothetical egd chardev would have to duplicate 100% of the socket chrdev logic. > I think rate-limiting is more generically useful as a 'line > discipline'-like feature, to work with any chardev type. But it > should then have properties governing incoming and outgoing rate > limiting separately, which won't get much testing for the only > imminent user which is input-only. but again, qemu doesn't *have* line disciplines. -Ian