From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN82Z-0007x0-FK for qemu-devel@nongnu.org; Thu, 19 May 2011 14:33:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN82Y-00041T-FW for qemu-devel@nongnu.org; Thu, 19 May 2011 14:33:43 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:34591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN82Y-00041G-D4 for qemu-devel@nongnu.org; Thu, 19 May 2011 14:33:42 -0400 Received: by yxk8 with SMTP id 8so1194919yxk.4 for ; Thu, 19 May 2011 11:33:41 -0700 (PDT) Message-ID: <4DD56283.7060106@codemonkey.ws> Date: Thu, 19 May 2011 13:33:39 -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> <4DD55B55.5020701@codemonkey.ws> <20110519182809.GI27310@redhat.com> In-Reply-To: <20110519182809.GI27310@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 01:28 PM, Gleb Natapov wrote: > On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote: >> On 05/19/2011 12:39 PM, Gleb Natapov wrote: >> 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. Agreed. Minus PAM and SMM, RAM is always RAM. When a CPU accesses it, it's always the same. This is not the case for device accesses to RAM but this is probably a separate topic. >> 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. All platforms have in common the fact that I/O is dispatched in a hierarchical fashion. The reason is quite simple--physics only allow so many point-to-point connections between components. So I/O access is always going to fan out. The components closer to the source of the I/O access are always able to overrule the lower components. Regards, Anthony Liguori >>> 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. >