From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDqSG-0005TV-WB for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:52:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDqSC-0002Ew-1U for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:52:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDqSB-0002Eq-RM for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:52:43 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 223B48F22F for ; Fri, 17 Jun 2016 09:52:43 +0000 (UTC) Date: Fri, 17 Jun 2016 11:52:39 +0200 From: Igor Mammedov Message-ID: <20160617115239.035fb544@nial.brq.redhat.com> In-Reply-To: <1466155074.18921.16.camel@redhat.com> References: <1466097133-5489-1-git-send-email-dgilbert@redhat.com> <1466097133-5489-5-git-send-email-dgilbert@redhat.com> <20160616202449.GY18662@thinpad.lan.raisama.net> <20160617081505.GA2273@work-vm> <08f8e4e0-781a-d7f2-9008-3274f8a085eb@redhat.com> <1466155074.18921.16.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paolo Bonzini , aarcange@redhat.com, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , Eduardo Habkost , Laszlo Ersek On Fri, 17 Jun 2016 11:17:54 +0200 Gerd Hoffmann wrote: > On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote: > > > > On 17/06/2016 10:15, Dr. David Alan Gilbert wrote: > > > Larger is a problem if the guest tries to map something to a high > > > address that's not addressable. > > > > Right. It's not a problem for most emulated PCI devices (it would be a > > problem for those that have large RAM BARs, but even our emulated video > > cards do not have 64-bit RAM BARs, I think; > > qxl can be configured to have one, try "-device > qxl-vga,vram64_size_mb=1024" > > > > 2) While we have maxmem settings to tell us the top of VM RAM, do > > > we have anything that tells us the top of IO space? What happens > > > when we hotplug a PCI card? > > > (arch/x86/kernel/setup.c) but I agree that (2) is a blocker. > > seabios maps stuff right above ram (possibly with a hole due to > alignment requirements). > > ovmf maps stuff into a 32G-aligned 32G hole. Which lands at 32G and > therefore is addressable with 36 bits, unless you have tons of ram (> > 30G) assigned to your guest. A physical host machine where you can plug > in enough ram for such a configuration likely has more than 36 physical > address lines too ... > > qemu checks where the firmware mapped 64bit bars, then adds those ranges > to the root bus pci resources in the acpi tables (see /proc/iomem). > > > You don't know how the guest will assign PCI BAR addresses, and as you > > said there's hotplug too. > > Not sure whenever qemu adds some extra space for hotplug to the 64bit > hole and if so how it calculates the size then. But the guest os should > stick to those ranges when configuring hotplugged devices. currently firmware would assign 64-bit BARs after reserved-memory-end (not sure about ovmf though) but QEMU on ACPI side will add 64-bit _CRS only for firmware mapped devices (i.e. no space reserved for hotplug). And is I recall correctly ovmf won't map BARs if it doesn't have a driver for it so ACPI tables won't even have a space for not mapped 64-bit BARs. There was another attempt to reserve more space in _CRS https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00090.html > > cheers, > Gerd > >