From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLEAL-00022M-2A for qemu-devel@nongnu.org; Thu, 07 Jul 2016 14:36:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLEAG-00027N-TK for qemu-devel@nongnu.org; Thu, 07 Jul 2016 14:36:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLEAG-00027I-LE for qemu-devel@nongnu.org; Thu, 07 Jul 2016 14:36:44 -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 F401A63E17 for ; Thu, 7 Jul 2016 18:36:43 +0000 (UTC) Date: Thu, 7 Jul 2016 19:36:39 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160707183638.GD2458@work-vm> References: <1467745398-28183-1-git-send-email-dgilbert@redhat.com> <1467745398-28183-2-git-send-email-dgilbert@redhat.com> <20160706190110.GV4131@thinpad.lan.raisama.net> <20160707163913.GB2458@work-vm> <20160707180243.GI4131@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160707180243.GI4131@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [PATCH v3 1/4] x86: Allow physical address bits to be set 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 Thu, Jul 07, 2016 at 05:39:14PM +0100, Dr. David Alan Gilbert wrote: > [...] > > * Eduardo Habkost (ehabkost@redhat.com) wrote: > > > On Tue, Jul 05, 2016 at 08:03:15PM +0100, Dr. David Alan Gilbert (git) wrote: > > > > From: "Dr. David Alan Gilbert" > > > > > > > > Currently QEMU sets the x86 number of physical address bits to the > > > > magic number 40. This is only correct on some small AMD systems; > > > > Intel systems tend to have 36, 39, 46 bits, and large AMD systems > > > > tend to have 48. > > > > > > > > Having the value different from your actual hardware is detectable > > > > by the guest and in principal can cause problems; > > > > The current limit of 40 stops TB VMs being created by those lucky > > > > enough to have that much. > > > > > > > > This patch lets you set the physical bits by a cpu property but > > > > defaults to the same existing magic 40. > > > > > > > > I've removed the ancient warning about the 42 bit limit in exec.c; > > > > I can't find that limit in there and no one else seems to know where > > > > it is. > > > > > > > > We use a magic value of 9999 as the property default so that we can > > > > later distinguish between the default and a user set value. > > > > > > I'd prefer to use -1 or 0xFFFFFFFF (UINT32_MAX) to indicate it > > > was not set by the user, and not document it as "use the old > > > default" but just as "it was not set explicitly". > > > > > > This won't allow us to differentiate between "set by user" and > > > "set by machine-type compat_props" in the future. But I would > > > prefer to use a MachineClass field or boolean property than magic > > > numbers for that, anyway. > > > > > > If you replace 9999 with UINT32_MAX or 0xFFFFFFFF in this patch: > > > > > > Reviewed-by: Eduardo Habkost > > > > > > BTW, using 0 to indicate "not set" would be acceptable, too, but > > > the magic 0 value in patch 4/4 would need to be replaced with a > > > boolean "host-phys-bits" property. But I prefer boolean properties > > > instead of magic numbers, anyway. > > > > OK, lets do that then. I'll use 0 here for the magic default > > and then add the host-phys-bits boolean that strictly overrides > > the phys-bits numeric. > > > > I didn't use UINT32_MAX or 0xffffffff because I wasn't convinced > > how that would interact with the machine-type/compat code which > > uses strings to represent default values for machine types. > > Good point. Integer parsing code in QEMU is ... interesting. > > > > > (And we have ~40 cases of DEFINE_PROP_UINT*(.....,-1) which I just > > find very wrong). > > Just wait until you see how string-input-visitor.c parses > uint64_t values. Blech! Dave > > -- > Eduardo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK