From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55169) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW0Zg-0002bf-9b for qemu-devel@nongnu.org; Tue, 15 Oct 2013 05:06:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VW0ZV-0000ym-DQ for qemu-devel@nongnu.org; Tue, 15 Oct 2013 05:05:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW0ZV-0000xC-4l for qemu-devel@nongnu.org; Tue, 15 Oct 2013 05:05:45 -0400 Date: Tue, 15 Oct 2013 12:08:15 +0300 From: "Michael S. Tsirkin" Message-ID: <20131015090815.GA5169@redhat.com> References: <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> <20131014140047.GA5106@redhat.com> <1381824061.3709.20.camel@nilsson.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381824061.3709.20.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 Tue, Oct 15, 2013 at 10:01:01AM +0200, Gerd Hoffmann wrote: > Hi, > > > 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. > > We are reaching the point where it becomes pointless bikeshedding ... > > I want a interface which is clearly defined and which doesn't break if > the way we use the address space above 4g changes (hotplug, > non-contignous memory, whatever). So make it depend on the memory > deployed isn't a clever idea. > > So at the end of the day it comes down to specify an address, either > relative to 4g (your reserve-memory-over-4g suggestion) or relative to > zero (Igors pcimem64-start patch). Both will do the job. In both cases > the bios has to check it has no conflicts with known ram regions (i.e. > compare against 1<<32 + RamSizeAbove4G). Actually it doesn't: bios doesn't use RAM above 4G value. It passes it to guest but ignores it itself. So you can likely boot guest and let it figure it out. > > I personally don't see the point in having the address relative to 4g > and prefer the pcimem64-start approach. We could rename it to > pcimem64-minimum-address to make more clear this is about keeping some > space free rather than specifyng a fixed address where the 64bit pci > bars should be mapped to. But at the end of the day I don't care too > much, how we are going to name the baby is just a matter of taste and > not really critical for the interface ... I agree with this last claim. Finding a nice name > What is the state of the qemu side patches btw? > > cheers, > Gerd >