From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGnZX-0008IS-84 for qemu-devel@nongnu.org; Mon, 11 Aug 2014 07:15:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGnZT-0008VG-EC for qemu-devel@nongnu.org; Mon, 11 Aug 2014 07:15:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGnZT-0008VC-6z for qemu-devel@nongnu.org; Mon, 11 Aug 2014 07:15:23 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7BBFM8Y025189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 11 Aug 2014 07:15:22 -0400 Date: Mon, 11 Aug 2014 12:15:18 +0100 From: "Daniel P. Berrange" Message-ID: <20140811111518.GQ11762@redhat.com> References: <1406121438-23083-1-git-send-email-lcapitulino@redhat.com> <1406121438-23083-3-git-send-email-lcapitulino@redhat.com> <20140811081719.GA11762@redhat.com> <87lhqv2sjc.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87lhqv2sjc.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [RFC 2/3] QMP: rate limit BLOCK_IO_ERROR Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Mon, Aug 11, 2014 at 01:07:51PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > For the BLOCK IO ERROR events this does not work because the events are > > device and operation specific. > > > > QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=read action=stop > > QAPI_EVENT_BLOCK_IO_ERROR dev=scsi1-hd2 op=write action=stop > > QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=write action=stop > > > > with throttling the app wll only receive > > > > QAPI_EVENT_BLOCK_IO_ERROR dev=ide0-hd1 op=write action=stop > > > > which means it will have an *incorrect* view of the system state because > > the info about scsi1-hd2 is irretrievably lost, likewise info about the > > read operation of ide0-hd1. > > Even when the event is lost, the information should not be lost. There > should be a way to poll for it (libvirt needs that anyway, to cope with > possible event loss during a libvirt restart). Yes, that's true. > > If you want to throttle BLOCK IO ERROR events, then you need to make the > > monitor throttling more intelligent, so that it hashes on all the contextual > > state. In this case you'd have to throttle based on (event, dev, op) to get > > correct application behaviour. > > I think there's more than one to skin this cat: > > 1. Don't throttle. Client can rely on events as long as it keeps the > QMP connection alive. Client should poll after establishing the QMP > connection. A malicious guest OS can flood libvirt with events in this way. Of course even if we throttle, a compromised QEMU can still flood libvirt. The only fail-safe protection is for libvirt to detect flooding and throttle the rate at which it talks to the (malicious) QEMU. > 2. Throttle more smartly, so that events only get dropped when they're > semantically superseded. I figure that's what you proposed in your > last paragraph. Yep, that's what I was suggesting. > 3. Throttle, but accumulate the information carried by the event, i.e. > any dropped events' data is sent with the next non-dropped event. I fear this could get rather ugly - fields which are currently scalar quantities would need to become lists or hashes. > 4. Throttle without smarts or accumulation. > > a. The event's additional information may be incomplete, thus > worthless. Client needs too poll after getting an event. Might as well just not bother sending any additionl info in events if we took this path. > > b. Add a flag "throttling has dropped some events". The additional > information is incomplete when the flag is set. Client needs to > poll then. This is a reasonable idea too. > Backward compatibility considerations may narrow our choice. I think 1, 2 or 4b are viable from a general design POV, but only 1 or 2 are viable from a back-compat POV, unless there was an explicit command that client apps issued to turn on the throttling in 4b instead of it being on by default. Regards, 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 :|