From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLD9O-0004fy-2l for qemu-devel@nongnu.org; Sun, 15 Sep 2013 10:18:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLD9I-0002sD-3i for qemu-devel@nongnu.org; Sun, 15 Sep 2013 10:18:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLD9H-0002s9-Sg for qemu-devel@nongnu.org; Sun, 15 Sep 2013 10:18:04 -0400 Date: Sun, 15 Sep 2013 17:20:09 +0300 From: "Michael S. Tsirkin" Message-ID: <20130915142009.GA18383@redhat.com> References: <20130915071445.GA29806@redhat.com> <20130915110552.GA4600@redhat.com> <20130915121750.GB4600@redhat.com> <20130915133944.GA5219@redhat.com> <20130915140856.GA18362@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , Anthony Liguori , Jan Kiszka , QEMU Developers , Marcel Apfelbaum On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote: > On 15 September 2013 15:08, Michael S. Tsirkin wrote: > > On Sun, Sep 15, 2013 at 02:49:32PM +0100, Peter Maydell wrote: > >> Yes, but if we were applying a sensible set of priorities > >> then you don't need to care at all about the contents > >> of the pci hole container, because the pci hole will > >> be at a lower priority then mcfg; so you don't get into > >> this odd corner case of "what happens if the high > >> priority container turns out not to have anything there". > > > So setting sensible priorities in this case would require figuring out > > what happens on real hardware. > > As long as no one investigated, I think we are better off > > leaving this as undefined behaviour. > > Well, that's your choice, but I'd be really surprised if the > PCI controller allowed PCI BARs to get mapped over the > top of builtin devices like that. Well it has no way not to allow this, what happens in this configuration is another matter. > > Again, the changes you proposed yourself to support MA status bit > > means we will be using this weird feature on each and every > > PCI bus :) > > It's still an odd corner case that only the PCI controller > core code needs to care about Actually you previosly wrote: > the versatilePB's PCI controller only responds to accesses > within its programmed MMIO BAR ranges, so if the device > or the controller have been misconfigured you can get an > abort when the device tries to do DMA. Doesn't this mean versatilePB will have to have similar code in it's PCI controller implementation - outside PCI controller core? Also, PCI bridge core code will care about this as well. > (compared to the much > larger set of container uses in random other boards and > devices we have). > > -- PMM Right. I guess that's because most boards are not as configurable as PCI. -- MST