From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFqpI-00074P-8C for qemu-devel@nongnu.org; Wed, 22 Jun 2016 18:40:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFqpD-0001yq-VE for qemu-devel@nongnu.org; Wed, 22 Jun 2016 18:40:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFqpD-0001yh-I6 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 18:40:47 -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 CF757C05681D for ; Wed, 22 Jun 2016 22:40:46 +0000 (UTC) Date: Thu, 23 Jun 2016 01:40:42 +0300 From: "Michael S. Tsirkin" Message-ID: <20160622224042.GA29641@redhat.com> References: <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> <20160617151900.GE18662@thinpad.lan.raisama.net> <20160617154905.GH18662@thinpad.lan.raisama.net> <20160621194440.GN17952@thinpad.lan.raisama.net> <9b76415a-23e6-3ded-4dbc-42838cc164b0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b76415a-23e6-3ded-4dbc-42838cc164b0@redhat.com> Subject: Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [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 , aarcange@redhat.com, Marcel Apfelbaum , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org On Wed, Jun 22, 2016 at 02:41:22PM +0200, Paolo Bonzini wrote: > > > On 21/06/2016 21:44, Eduardo Habkost wrote: > > The consequences of migrating (or having migration blocked) to a > > host with smaller phys-addr-bits sound worse to me than the > > consequences of just having guest's phys-addr-bits smaller than > > the host's. > > There is no correct answer. We've been using host phys-addr-bits in > RHEL for 6 years and no one has ever reported a bug. > > Most data centers (the ones that actually use migration) will all have > Xeon E5s and above, and pretty much all of them have 46-bits physical > address bits since at least Sandy Bridge. That probably helps. > Save/restore is usually done on the same machine, which also helps > because host phys-addr-bits doesn't change. > > >From a semantics point of view, using a smaller phys-addr-bits than the > host is the worst, because you tell the guest that some bits are > must-be-zero, when they're not. Using a larger phys-addr-bits cannot > cause malfunctioning, only crashes (and as Gerd said, if you cross your > fingers and hope the guest doesn't put anything so high in memory, > chances are you'll succeed), and this makes it "safer". I'm not sure > which one is more likely to happen. > > So there's no correct answer, Wait a second: 1. Use CPUID to tell guest it can address 46 bits 2. use e820 to tell guest RAM has addresses below e.g. 39 bits 3. _CRS to tell guest not to put anything above e.g. 39 bits will result in guest never using any addresses above 39 bits but also always setting bits 39 to 46 to zero. No crashes, no corruptions. Where's a problem then? > and that's why I think the lesser evil is > to go with the time-tested alternative and use host phys-addr-bits as > the default, even if it causes weird behavior on migration. If a fixed > phys-addr-bits is specified on the destination, it should match the > value that was used on the source though. > > Paolo I agree, but I don't see a need to use host bits at all. So I think that all we need is a way to let libvirt control the _CRS range. Teach it that _CRS must fit within what host can support. Also check and fail kvm init if _CRS exceeds what host can support. Hmm? -- MST