From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Ei2-0001P8-AM for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:34:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Ei1-0004Fw-49 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:34:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Ei0-0004Fn-Mn for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:34:09 -0400 Message-ID: <4E639A68.1090909@redhat.com> Date: Sun, 04 Sep 2011 18:34:00 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5D39C8.5020205@web.de> <4E5E1297.3050904@siemens.com> <4E628607.20309@codemonkey.ws> <4E636B56.9070808@web.de> <4E637E06.9020206@codemonkey.ws> <4E637EEA.1030502@web.de> <4E638010.9010503@codemonkey.ws> <4E638746.6040808@redhat.com> <4E638EA7.8040806@codemonkey.ws> <4E639337.2050209@redhat.com> <4E6396F6.9040200@codemonkey.ws> In-Reply-To: <4E6396F6.9040200@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Peter Maydell , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann On 09/04/2011 06:19 PM, Anthony Liguori wrote: >>> Yes, and the memory API is complicated and invasive :-) But it's worth >>> it at the end of the day (although I think it could be simplified at >>> the expensive of not allowing as much flattening). >> >> (we should have spent a few hours at kf2011 to convince you that this is >> impossible) > > > I don't mean for RAM, but for device I/O. It's impossible to make the distinction. A piece of RAM can overlay an mmio region and split it in two, or an mmio region can split a RAM region. This means the machinery cannot consider the region type anyway. > > Instead of implementing it_shift in the core API, you could implement > it_shift by having a device that takes an input MemoryRegion and an > output MemoryRegion and implements the it_shift logic. We could, but that imposes a burden on users to find that device and glue it to the memory API. I'm not after a mean and lean API, I'm after something that is easy enough to use that people manage to get device models that work. > > I think endianness could also be handled this way too. On some archs, endianness can find itself in RAM, so we need complete control. And again, I don't want users gluing stuff together the wrong way, I want them using a simple interface. -- error compiling committee.c: too many arguments to function