From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si3S0-0007tx-6v for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:59:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Si3Ry-0000zL-Ch for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:58:59 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:60581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si3Ry-0000zE-6f for qemu-devel@nongnu.org; Fri, 22 Jun 2012 08:58:58 -0400 Received: by pbbro12 with SMTP id ro12so3635466pbb.4 for ; Fri, 22 Jun 2012 05:58:56 -0700 (PDT) Message-ID: <4FE46C0D.5070404@codemonkey.ws> Date: Fri, 22 Jun 2012 07:58:53 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FE240B2.4070907@codemonkey.ws> <4FE4639B.5070805@codemonkey.ws> <20120622123123.GJ10128@redhat.com> In-Reply-To: <20120622123123.GJ10128@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 1/1] virtio-rng: hardware random number generator device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Amit Shah , Markus Armbruster , qemu list On 06/22/2012 07:31 AM, Daniel P. Berrange wrote: > 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 BTW, in the current design, there's no way to tell *which* virtio-rng device needs entropy if you have multiple virtio-rng devices. All of these problems are naturally solved using a protocol over a CharDriverState. Regards, Anthony Liguori > > > Daniel