From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52814)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bG0BI-0006zr-A3
	for qemu-devel@nongnu.org; Thu, 23 Jun 2016 04:40:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bG0BD-000306-BB
	for qemu-devel@nongnu.org; Thu, 23 Jun 2016 04:40:11 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36619)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1bG0BD-0002yj-52
	for qemu-devel@nongnu.org; Thu, 23 Jun 2016 04:40:07 -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 0E55564094
	for <qemu-devel@nongnu.org>; Thu, 23 Jun 2016 08:40:06 +0000 (UTC)
Message-ID: <1466671203.26189.35.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 23 Jun 2016 10:40:03 +0200
In-Reply-To: <20160623024400-mutt-send-email-mst@redhat.com>
References: <20160617131815.GA18662@thinpad.lan.raisama.net>
	<a9a5a663-91d4-b8bc-7502-6e9520a0763f@redhat.com>
	<20160617151900.GE18662@thinpad.lan.raisama.net>
	<deb30133-e84e-2c09-cc22-b34d1e9f3d90@redhat.com>
	<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>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>, Marcel Apfelbaum <marcel@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>, "Dr. David
	Alan Gilbert" <dgilbert@redhat.com>

  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.
>=20
> 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 ...

cheers,
  Gerd