From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgFI-0001te-Q5 for qemu-devel@nongnu.org; Mon, 11 Jul 2016 14:47:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMgFE-0001Pd-Ij for qemu-devel@nongnu.org; Mon, 11 Jul 2016 14:47:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMgFE-0001PY-D5 for qemu-devel@nongnu.org; Mon, 11 Jul 2016 14:47:52 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 4793C7F352 for ; Mon, 11 Jul 2016 18:47:51 +0000 (UTC) Date: Mon, 11 Jul 2016 19:47:47 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160711184746.GH2078@work-vm> References: <1467990099-27853-1-git-send-email-dgilbert@redhat.com> <1467990099-27853-6-git-send-email-dgilbert@redhat.com> <20160708231601.GR4131@thinpad.lan.raisama.net> <20160711153921.GD2078@work-vm> <20160711184249.GW4131@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160711184249.GW4131@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH v4 5/5] x86: Set physical address bits based on host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, marcel@redhat.com, mst@redhat.com, kraxel@redhat.com * Eduardo Habkost (ehabkost@redhat.com) wrote: > On Mon, Jul 11, 2016 at 04:39:22PM +0100, Dr. David Alan Gilbert wrote: > > * Eduardo Habkost (ehabkost@redhat.com) wrote: > [...] > > > > + cpu->phys_bits = TCG_PHYS_ADDR_BITS; > > > > + } > > > > } else { > > > > /* For 32 bit systems don't use the user set value, but keep > > > > * phys_bits consistent with what we tell the guest. > > > > > > Shouldn't we return error if host-phys-bits is set in 32-bit > > > mode? > > > > I've just realised there's a reason that erroring in this case is a problem. > > Imagine a future (or downstream) machine type that made host-phys-bits the default; > > how would it run with a 32bit CPU? > > Oh, that's right. Ignoring it when explicitly set isn't > intuitive, but we need to be able to ignore it when set by a > machine compat_props (or if it's enabled by default). And > creating two separate properties sounds like overkill... > I'm reluctant, but I think it's OK to ignore it if LM is not set. > But we need to make sure it's documented somewhere. OK, I'll add a comment and a note in the commit message. Dave > > -- > Eduardo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK