From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDvY4-0001ja-Ni for qemu-devel@nongnu.org; Fri, 17 Jun 2016 11:19:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDvXy-0000HA-Lk for qemu-devel@nongnu.org; Fri, 17 Jun 2016 11:19:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDvXy-0000H5-Fn for qemu-devel@nongnu.org; Fri, 17 Jun 2016 11:19:02 -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 0EC7B7F6A5 for ; Fri, 17 Jun 2016 15:19:02 +0000 (UTC) Date: Fri, 17 Jun 2016 12:19:00 -0300 From: Eduardo Habkost Message-ID: <20160617151900.GE18662@thinpad.lan.raisama.net> 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: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, aarcange@redhat.com, Marcel Apfelbaum , "Michael S. Tsirkin" On Fri, Jun 17, 2016 at 03:38:53PM +0200, Paolo Bonzini wrote: > > > On 17/06/2016 15:18, 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; > >>> > >>> What kind of problems? > >>> > >>> Is it a problem to have something smaller from the actual > >>> hardware, or just if it's higher? > >> > >> I'm a bit vague on the failure cases; but my understanding of the two > >> cases are; > >> > >> Larger is a problem if the guest tries to map something to a high > >> address that's not addressable. > > (Note: this is a problem when migrating to hosts with _smaller_ > phys-bits) > > >> Smaller is potentially a problem if the guest plays tricks with > >> what it thinks are spare bits in page tables but which are actually > >> interpreted. I believe KVM plays a trick like this. > > (Note: this is a problem when migrating to hosts with _larger_ > phys-bits) > > > If both smaller and larger are a problem, we have a much bigger > > problem than we thought. We need to confirm this. > > > > So, what happens if the guest play tricks in bits 40-45 when QEMU > > sets the limit to 40 but we are running in a 46-bit host? Is it > > really a problem? I assumed it would be safe. > > The guest expects a "reserved bit set" page fault, but doesn't get one. Wait, are you talking about migration only, or are you really talking about running current QEMU (hardcoded to 40) on a 46-bit host? I'm not talking about migration, above. We really can't emulate a 40-bit machine in a 46-bit host? I didn't expect that. -- Eduardo