From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si31X-0002Vf-IG for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:31:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Si31O-0003SB-Lf for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:31:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si31O-0003S4-DL for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:31:30 -0400 Date: Fri, 22 Jun 2012 13:31:24 +0100 From: "Daniel P. Berrange" Message-ID: <20120622123123.GJ10128@redhat.com> References: <4FE240B2.4070907@codemonkey.ws> <4FE4639B.5070805@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FE4639B.5070805@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH v3 1/1] virtio-rng: hardware random number generator device Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Markus Armbruster , qemu list On Fri, Jun 22, 2012 at 07:22:51AM -0500, Anthony Liguori wrote: > On 06/22/2012 07:12 AM, Markus Armbruster wrote: > >Anthony Liguori writes: > >>Nack. > >> > >>Use a protocol. This is not what QMP events are designed for! > >> > >>No human is going to launch nc to a unix domain socket to launch QEMU. > >>That's a silly use-case to design for. > > > >To be honest, I'm a bit surprised to see working code that got an ACK > >from the guys with the problem it solves rejected out of hand over > >something that feels like artistic license to me. > > This is an ABI! We have to support it for the rest of time. > Everything else is a detail that is fixable but ABIs need to not > suck from the beginning. > > And using a QMP event here is sucks. It disappoints me that this is > even something I need to explain. > > QMP events occur over a single socket. If you trigger them from > guest initiated activities (that have no intrinsic rate limit), you > run into a situation where the guest could flood the management tool > and/or queue infinite amounts of memory (because events have to be > queued before they're sent). So we have rate limiting for QMP > events. > > That means QMP events (like this one) are unreliable. No it doesn't. As it stands currently, the only events that are rate limited, are those where there is no state information to loose. ie, the new event completely superceeds the old event without loosing any information. > But since QMP > events aren't acked, there's no way for the management tool to know > whether a QMP event was dropped or not. So you can run into the > following scenario: > > - Guest sends randomness request for 10 bytes > - QMP event gets sent for 10 bytes > - Guest sends randomness request for 4 bytes > - QMP is dropped > > Now what happens? With the current virtio-rng, nothing. It gets > stuck in read() for ever. Now what do we do? The RNG event will not be able to use the generic rate limiting since it has state associated with it. The rate limiting of the RNG QMP event will need to take account of this state, ie it will have to accumulate the byte count of any events dropped for rate limiting: - Guest sends randomness request for 10 bytes - QMP event gets sent for 10 bytes - Guest sends randomness request for 4 bytes - QMP is dropped - Guest sends randomness request for 8 bytes - QMP event gets sent for 12 bytes Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|