From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIIZq-0008Lk-1I for qemu-devel@nongnu.org; Wed, 29 Jun 2016 12:43:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIIZm-0002aK-9Q for qemu-devel@nongnu.org; Wed, 29 Jun 2016 12:43:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIIZm-0002Zi-1H for qemu-devel@nongnu.org; Wed, 29 Jun 2016 12:42:58 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 2AC1DC049D67 for ; Wed, 29 Jun 2016 16:42:57 +0000 (UTC) Date: Wed, 29 Jun 2016 17:42:53 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160629164252.GD10488@work-vm> References: <20160617151900.GE18662@thinpad.lan.raisama.net> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1466671203.26189.35.camel@redhat.com> 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: Gerd Hoffmann Cc: "Michael S. Tsirkin" , Andrea Arcangeli , Marcel Apfelbaum , Paolo Bonzini , qemu-devel@nongnu.org, Eduardo Habkost * Gerd Hoffmann (kraxel@redhat.com) wrote: > Hi, > > > > Well the crash of guest phys bits > host phys bits, should be easy to > > > reproduce by booting a 65GB guest on a 64GB RAM + 2GB swap host with > > > 36 host phys bits using the upstream qemu that forces the guest phys > > > bits to 40. > > > > So you supply more RAM than host can address, and guest crashes? > > Yep. The only reason we don't see this happening in practice is that > it's probably next to impossible to find a machine which has (a) only 36 > physical address lines and (b) allows to plug that much RAM. > > > Why are we worried about it? > > It's more a issue with pci ressources. In theory seabios/edk2 could go > figure how big the physical address space is, then map 64bit pci bars as > high as possible, thereby making stuff like etc/reserved-memory-end in > fw_cfg unnecessary. > > But with qemu saying 40 phys bits are available even if they are not > this approach isn't going to fly ... Something somewhere in qemu/ kernel/ firmware is already reading the number of physical bits to determine PCI mapping; if I do: ./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm,usb=off -m 4096,slots=16,maxmem=128T -vga none -device qxl-vga,bus=pcie.0,ram_size_mb=2048,vram64_size_mb=2048 -vnc 0.0.0.0:0 /home/vms/7.2a.qcow2 -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -cpu host,phys-bits=48 it will happily map the qxl VRAM right up high, but if I lower the phys-bits down to 46 it won't. VGA controller: PCI device 1b36:0100 IRQ 11. BAR0: 32 bit memory at 0xc0000000 [0xdfffffff]. BAR1: 32 bit memory at 0xe0000000 [0xe3ffffff]. BAR2: 32 bit memory at 0xe4070000 [0xe4071fff]. BAR3: I/O at 0xc080 [0xc09f]. BAR4: 64 bit prefetchable memory at 0x800480000000 [0x8004ffffffff]. BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe]. id "" I'll admit to not understanding why it all still boots and doesn't fall in a mess with that mapping (46 bit Xeon). Dave > > cheers, > Gerd > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK