From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtgVe-0003ZM-I6 for qemu-devel@nongnu.org; Wed, 17 Aug 2011 09:50:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtgVZ-0008EZ-QS for qemu-devel@nongnu.org; Wed, 17 Aug 2011 09:50:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtgVZ-0008EU-JG for qemu-devel@nongnu.org; Wed, 17 Aug 2011 09:50:13 -0400 Message-ID: <4E4BC711.7050402@redhat.com> Date: Wed, 17 Aug 2011 06:50:09 -0700 From: Avi Kivity MIME-Version: 1.0 References: <1313513145-5348-1-git-send-email-rth@twiddle.net> <1313513145-5348-3-git-send-email-rth@twiddle.net> <4E4BC5FA.1020409@redhat.com> In-Reply-To: <4E4BC5FA.1020409@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/14] isa: Add isa_register_old_portio_list(). List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On 08/17/2011 06:45 AM, Avi Kivity wrote: > >> +{ >> + MemoryRegion *io_space = isabus->address_space_io; >> + const MemoryRegionPortio *pio_iter; >> + >> + /* START is how we should treat DEV, regardless of the actual >> + contents of the portio array. This is how the old code >> + actually handled e.g. the FDC device. */ >> + if (dev) { >> + isa_init_ioport(dev, start); >> + } >> + >> + for (; pio_start->size != 0; pio_start = pio_iter + 1) { >> + unsigned int off_low = UINT_MAX, off_high = 0; >> + MemoryRegionOps *ops; >> + MemoryRegion *region; >> + >> + for (pio_iter = pio_start; pio_iter->size; ++pio_iter) { >> + if (pio_iter->offset< off_low) { >> + off_low = pio_iter->offset; >> + } >> + if (pio_iter->offset + pio_iter->len> off_high) { >> + off_high = pio_iter->offset + pio_iter->len; >> + } > > This is supposed to pick up MRPs that are for the same port address? > If so that should be in the loop termination condition. Oh, after seeing a user I see how it works now. But can't we derive this information instead of forcing the user to specify it? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.