From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:52029)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Qk9na-0006zA-Hp
	for qemu-devel@nongnu.org; Fri, 22 Jul 2011 03:05:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Qk9nZ-0000Vj-BI
	for qemu-devel@nongnu.org; Fri, 22 Jul 2011 03:05:26 -0400
Received: from mx1.redhat.com ([209.132.183.28]:17149)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1Qk9nZ-0000Vd-1d
	for qemu-devel@nongnu.org; Fri, 22 Jul 2011 03:05:25 -0400
Message-ID: <4E29212D.6020209@redhat.com>
Date: Fri, 22 Jul 2011 10:05:17 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1311180636-17012-1-git-send-email-avi@redhat.com>
	<1311180636-17012-13-git-send-email-avi@redhat.com>
	<CAAu8pHuq37t2T9RPhM9eGez8KAaMHMJFJAXfTMomsHBFK54o_w@mail.gmail.com>
In-Reply-To: <CAAu8pHuq37t2T9RPhM9eGez8KAaMHMJFJAXfTMomsHBFK54o_w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC v5 12/86] memory: add ioeventfd support
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

On 07/21/2011 10:55 PM, Blue Swirl wrote:
> On Wed, Jul 20, 2011 at 7:49 PM, Avi Kivity<avi@redhat.com>  wrote:
> >  As with the rest of the memory API, the caller associates an eventfd
> >  with an address, and the memory API takes care of registering or
> >  unregistering when the address is made visible or invisible to the
> >  guest.
> >
> >  +
> >  +static bool memory_region_ioeventfd_before(MemoryRegionIoeventfd a,
> >  +                                           MemoryRegionIoeventfd b)
> >  +{
> >  +    if (a.addr.start<  b.addr.start) return true;
> >  +    if (a.addr.start>  b.addr.start) return false;
> >  +    if (a.addr.size<  b.addr.size) return true;
> >  +    if (a.addr.size>  b.addr.size) return false;
> >  +    if (a.match_data<  b.match_data) return true;
> >  +    if (a.match_data>  b.match_data) return false;
> >  +    if (a.match_data) {
> >  +        if (a.data<  b.data) return true;
> >  +        if (a.data>  b.data) return false;
> >  +    }
> >  +    if (a.fd<  b.fd) return true;
> >  +    if (a.fd>  b.fd) return false;
>
> NACK for CO.. Wait, is this another trap?

This is already fixed in my tree; v5 was already posted when you made 
your review (or at least, when I read it).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.