From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7xI-0006Nf-55 for qemu-devel@nongnu.org; Thu, 19 May 2011 14:28:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN7xH-0002rO-9j for qemu-devel@nongnu.org; Thu, 19 May 2011 14:28:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7xH-0002rK-13 for qemu-devel@nongnu.org; Thu, 19 May 2011 14:28:15 -0400 Date: Thu, 19 May 2011 21:28:09 +0300 From: Gleb Natapov Message-ID: <20110519182809.GI27310@redhat.com> References: <4DD3C5B9.1080908@redhat.com> <4DD420A5.2020606@web.de> <4DD51CF3.5040306@codemonkey.ws> <4DD51D36.7040504@siemens.com> <20110519173923.GF27310@redhat.com> <4DD55B55.5020701@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD55B55.5020701@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , Avi Kivity , qemu-devel On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote: > 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. > Very likely. > 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. I think it should continue using it even when PCI BAR is still mapped to the RAM 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. > For PC may be. But IIRC this thread already had request to support different memory view from different devices. > >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. > Of course, my question is how proposed API handles this. -- Gleb.