From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVifB-0006nD-Mn for qemu-devel@nongnu.org; Mon, 14 Oct 2013 09:58:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVif3-0000lo-38 for qemu-devel@nongnu.org; Mon, 14 Oct 2013 09:58:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVif2-0000li-RI for qemu-devel@nongnu.org; Mon, 14 Oct 2013 09:58:17 -0400 Date: Mon, 14 Oct 2013 17:00:47 +0300 From: "Michael S. Tsirkin" Message-ID: <20131014140047.GA5106@redhat.com> References: <20131013155920.GC11448@redhat.com> <20131013182328.1e735051@thinkpad> <20131013164609.GA11934@redhat.com> <20131013193319.54578867@thinkpad> <20131013202847.GB12354@redhat.com> <20131014122726.7277bac0@nial.usersys.redhat.com> <20131014110012.GE30954@redhat.com> <1381752983.30262.32.camel@nilsson.home.kraxel.org> <20131014123854.GB31534@redhat.com> <1381755885.30262.58.camel@nilsson.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381755885.30262.58.camel@nilsson.home.kraxel.org> Subject: Re: [Qemu-devel] [PATCH v2] map 64-bit PCI BARs at location provided by emulator List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Igor Mammedov , kevin@koconnor.net, seabios@seabios.org, qemu-devel@nongnu.org, pbonzini@redhat.com On Mon, Oct 14, 2013 at 03:04:45PM +0200, Gerd Hoffmann wrote: > Hi, > > > > > > > To me it makes more sense to just go the direct route and say "please > > > put the 64bit bars at this location" rather than indirect "we might want > > > hotplug $thatmuch memory" and then expect the bios to leave that much > > > room. > > > > Only if the newfeature address is not under bios control. I know that > > bios is simplistic so all it cares about ATM is pci window, but can't > > shake the impression that we are better off telling the guest what's > > going on rather than what it should do. > > > > In particular the issue that was discussed (what to do > > if pci start is set by host to below ram end) > > will simply go away if we pass in an incremental > > value: there will be no invalid configurations. > > The "what is going on" might need updates in both qemu and seabios if > something new goes on. For example qemu getting support non-contignous > memory. The "leave that much address space free above memory" suddenly > is ambiguous as there are two (or more) memory blocks above 4g. "please > place 64bit pci bars there" continues to work just fine. Yes but at the cost of overspecifying it. I think it's down to the name: it's called pcimem64-start but it can actually be less than 4G and we need to worry what to do then. Also, 64 doesn't really mean >4G. So how about "reserve-memory-over-4g"? bios then does 1ull << 32 + reserve-memory-over-4g to figure out how much to skip. > > > > It's not unthinkable. > > > > Multiple ECAM regions (for multi-root systems) can make holes in the address space. > > > > > > Sounds pretty theoretic ... > > > > What? Multiple PCI roots? > > That we'll need pass multiple pci windows because of that. I expect > we'll need seabios support for the new multi-root hardware anyway, and > seabios will probably be aware of the hardware constrains then ... > > Also as far I know nobody is working on such a chipset. > > I simply wouldn't worry about that today. Designing a interface when > you don't know the exact needs for the it has a high chance to go wrong. Well you were the one that asked about that :) > > > > Also, we just ignore everything above the ioapic, but that's > > > > not a must, we could maybe use address space above ioapic. > > > > > > Any reason why we should that? > > > > > > > 32 bit address space is contrained, using it is preferable for > > 32 bit guests ... > > This wouldn't help in the cases I've seen in practice. We have no > problems at all to fit in mmio pci bars, even lots of them, they are > small enough. We can run out of address space if we have pci devices > with larger chunks of memory on them, such as qxl or ivshmem. And these > memory bars are too big to fit into any of the small holes above the > ioapic. > > cheers, > Gerd >