From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7Yw-0006Rp-Lw for qemu-devel@nongnu.org; Thu, 19 May 2011 14:03:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN7Yv-00073Q-Eo for qemu-devel@nongnu.org; Thu, 19 May 2011 14:03:06 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:48818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7Yv-00073M-8O for qemu-devel@nongnu.org; Thu, 19 May 2011 14:03:05 -0400 Received: by gwb19 with SMTP id 19so1177963gwb.4 for ; Thu, 19 May 2011 11:03:04 -0700 (PDT) Message-ID: <4DD55B55.5020701@codemonkey.ws> Date: Thu, 19 May 2011 13:03:01 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD420A5.2020606@web.de> <4DD51CF3.5040306@codemonkey.ws> <4DD51D36.7040504@siemens.com> <20110519173923.GF27310@redhat.com> In-Reply-To: <20110519173923.GF27310@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , Avi Kivity , qemu-devel On 05/19/2011 12:39 PM, Gleb Natapov wrote: > On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote: >> On 2011-05-19 15:36, Anthony Liguori wrote: >>> On 05/18/2011 02:40 PM, Jan Kiszka wrote: >>>> On 2011-05-18 15:12, Avi Kivity wrote: >>>>> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t >>>>> addr); >>>> >>>> OK, let's allow overlapping, but make it explicit: >>>> >>>> void cpu_register_memory_region_overlap(MemoryRegion *mr, >>>> target_phys_addr_t addr, >>>> int priority); >>> >>> The device doesn't actually know how overlapping is handled. This is >>> based on the bus hierarchy. >> >> Devices don't register their regions, buses do. >> > Today PCI device may register region that overlaps with any other > registered memory region without even knowing it. Guest can write any > RAM address into PCI BAR and this RAM address will be come mmio are. Right, but this is not how a real machine works. With the exception of the few regions that the chipset treats specially, RAM accesses don't get a chance to be intercepted by the PCI bus. > More > interesting is what happens when guest reprogram PCI BAR to other address > - the RAM that was at the previous address just disappears. Obviously > this is crazy behaviour, but the question is how do we want to handle The CPU should continue to access RAM at this address. It's unclear to me what the right behavior is for device-to-device I/O but I'm pretty certain it doesn't matter. > it? One option is to disallow such overlapping registration, another is > to restore RAM mapping after PCI BAR is reprogrammed. If we chose second > one the PCI will not know that _overlap() should be called. > > Another example may be APIC region and PCI. They overlap, but neither > CPU nor PCI knows about it. And APIC always wins when accesses are coming from the CPU. Regards, Anthony Liguori > > -- > Gleb. >