From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDpuZ-0001RZ-F6 for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:18:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDpuX-0002py-F2 for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:17:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDpuX-0002pk-9N for qemu-devel@nongnu.org; Fri, 17 Jun 2016 05:17:57 -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 7A73A81106 for ; Fri, 17 Jun 2016 09:17:56 +0000 (UTC) Message-ID: <1466155074.18921.16.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 17 Jun 2016 11:17:54 +0200 In-Reply-To: <08f8e4e0-781a-d7f2-9008-3274f8a085eb@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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 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: Paolo Bonzini Cc: "Dr. David Alan Gilbert" , Eduardo Habkost , aarcange@redhat.com, qemu-devel@nongnu.org On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote: >=20 > 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. >=20 > 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=3D1024" > > 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. cheers, Gerd