From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49620) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDuhp-00057J-Sz for qemu-devel@nongnu.org; Fri, 17 Jun 2016 10:25:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDuhi-0002cG-PU for qemu-devel@nongnu.org; Fri, 17 Jun 2016 10:25:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDuhi-0002bo-Id for qemu-devel@nongnu.org; Fri, 17 Jun 2016 10:25:02 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 677419B0F6 for ; Fri, 17 Jun 2016 14:25:01 +0000 (UTC) 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> From: Marcel Apfelbaum Message-ID: <57640839.2020909@redhat.com> Date: Fri, 17 Jun 2016 17:24:57 +0300 MIME-Version: 1.0 In-Reply-To: <20160617131815.GA18662@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Eduardo Habkost , "Dr. David Alan Gilbert" Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, aarcange@redhat.com, "Michael S. Tsirkin" On 06/17/2016 04:18 PM, Eduardo Habkost wrote: > On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote: >> * Eduardo Habkost (ehabkost@redhat.com) wrote: >>> On Thu, Jun 16, 2016 at 06:12:12PM +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; >>> [...] > >> 2) While we have maxmem settings to tell us the top of VM RAM, do >> we have anything that tells us the top of IO space? What happens >> when we hotplug a PCI card? > > (CCing Marcel and Michael, as we were discussing this recently.) > > That's a good question. When calculating how many bits the > machine requires, machine code could choose to reserve a > reasonable amount of space for hotplug by default. > Indeed we have a real problem with PCI hotplug. Numerous configurations (RAM size + devices present at boot) leave us with little (32bit PCI hole - devices present at boot) or none (if 32bit hole is full) MMIO for hotplug. We need a way to reserve [max-ram-including-hotplug-reserved-mem, x] range for this. But what is x? I thought cpu-max-addressable-addr is OK, now I don't think is not a good idea anymore because it will limit the migration only to hosts with at least same limit. (migrations that worked before will not work now) > Whatever we choose as the default, in some corner cases (e.g. > almost-32GB VMs running in a 39-bit host) we will still need to > let the user choose between having extra space for hotplug and > being able to safely migrate to 36-bit hosts. > > This can be solved by setting x86_64-cpu.phys-bits, but isn't it > too low level? We could have a higher level mechanism in the PC > machine class (e.g. a min-extra-phys-addr-space-for-hotplug > property). > I personally prefer min-extra-phys-addr-space-for-hotplug, but why min? I would go for phys-addr-space-for-hotplug that starts right after max-ram-including-hotplug-reserved-mem and is less than cpu-max-addressable-addr. But how to know cpu-max-addressable-addr? David's cpuid wrapper looks just fine, but I understood there are Windows versions that are not probing cpuid... Thanks, Marcel [...] [...]