From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bETXO-0002zP-Io for qemu-devel@nongnu.org; Sat, 18 Jun 2016 23:36:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bETXK-0002fA-BH for qemu-devel@nongnu.org; Sat, 18 Jun 2016 23:36:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bETXK-0002f6-5d for qemu-devel@nongnu.org; Sat, 18 Jun 2016 23:36:38 -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 D2AC685540 for ; Sun, 19 Jun 2016 03:36:36 +0000 (UTC) Date: Sun, 19 Jun 2016 06:36:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20160619063415-mutt-send-email-mst@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> <20160617131815.GA18662@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Eduardo Habkost , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, aarcange@redhat.com, Marcel Apfelbaum On Fri, Jun 17, 2016 at 03:38:53PM +0200, Paolo Bonzini wrote: > Making the guest's phys-bits larger than host-phys-bits would be okay if > you reserve the area in the e820 and assume the guest doesn't touch it. How would it touch it if there's no RAM there? PCI BARs is the only thing that comes to mind, but we fix that by making a sane _CRS. What did I miss? > But it is not a great idea too, because e820 describes RAM, so you're > telling the guest "look, there's 64 TB of reserved RAM up there". > > >> 3) Is it better to stick to sizes that correspond to real hardware > >> if you can? For example I don't know of any machines with 37 bits > >> - in practice I think it's best to stick with sizes that correspond > >> to some real hardware. > > > > Yeah, "as small as possible" could be actually "the smallest > > possible value from a set of known-to-exist values". e.g. if we > > find out that we need 37 bits, it's probably better to simply use > > 39 bits. > > > > Choosing from a smaller set of values also makes corner cases > > (like the example above) less likely to happen. > > Not really, because any value that doesn't match the host is > problematic, albeit in different ways. > > Paolo