From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIecC-00089P-LL for qemu-devel@nongnu.org; Thu, 30 Jun 2016 12:14:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIec8-0004QU-LX for qemu-devel@nongnu.org; Thu, 30 Jun 2016 12:14:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIec8-0004QQ-Fd for qemu-devel@nongnu.org; Thu, 30 Jun 2016 12:14:52 -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 47E1EC05E16C for ; Thu, 30 Jun 2016 16:14:51 +0000 (UTC) Message-ID: <1467303289.15123.102.camel@redhat.com> From: Gerd Hoffmann Date: Thu, 30 Jun 2016 18:14:49 +0200 In-Reply-To: <20160630105908.GA2683@work-vm> References: <20160617154905.GH18662@thinpad.lan.raisama.net> <20160621194440.GN17952@thinpad.lan.raisama.net> <9b76415a-23e6-3ded-4dbc-42838cc164b0@redhat.com> <20160622142414.GI30202@redhat.com> <20160623014216-mutt-send-email-mst@redhat.com> <20160622232308.GQ30202@redhat.com> <20160623024400-mutt-send-email-mst@redhat.com> <1466671203.26189.35.camel@redhat.com> <20160629164252.GD10488@work-vm> <1467267046.15123.94.camel@redhat.com> <20160630105908.GA2683@work-vm> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: "Michael S. Tsirkin" , Andrea Arcangeli , Marcel Apfelbaum , Paolo Bonzini , qemu-devel@nongnu.org, Eduardo Habkost > So that's mapped at an address beyond host phys-bits. > And it hasn't failed/crashed etc - but I guess maybe nothing is using tha= t 2G space? root@fedora ~# dmesg | grep Surface [ 4.830095] [drm] qxl: 2048M of Surface memory size qxl bar 4 (64bit) and qxl bar 1 (32bit) are the same thing. The 64bit bar can be alot larger obviously. The 32bit bar is just an alias for the first portion of the 64bit bar. So I guess qxl just falls back to use bar 1 instead of bar 4 because ioremap() on bar 4 fails. > Obviously 128T is a bit silly for maxmem at the moment, however I was wor= rying what > happens with 36/39/40bit hosts, and it's not unusual to pick a maxmem tha= t's a few TB > even if the VMs you're initially creating are only a handful of GB. (oVir= t/RHEV seems to use > a 4TB default for maxmem). Oh, ok. Should be fixed I guess. > Still, this only hits as a problem if you hit the combination of: > a) You use large PCI bars ovmf will map all 64bit bars high, even without running out of 32bit address space. And with virtio 1.0 pretty much every virtual machine will have 64bit bars. cheers, Gerd