From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56665)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aarcange@redhat.com>) id 1bFjO7-0006Ti-6z
	for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:44:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aarcange@redhat.com>) id 1bFjO1-00016a-87
	for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:44:19 -0400
Received: from mx1.redhat.com ([209.132.183.28]:56347)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aarcange@redhat.com>) id 1bFjO1-00016V-29
	for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:44:13 -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 64C6546211
	for <qemu-devel@nongnu.org>; Wed, 22 Jun 2016 14:44:12 +0000 (UTC)
Date: Wed, 22 Jun 2016 16:44:10 +0200
From: Andrea Arcangeli <aarcange@redhat.com>
Message-ID: <20160622144410.GL30202@redhat.com>
References: <20160617081505.GA2273@work-vm>
	<20160617131815.GA18662@thinpad.lan.raisama.net>
	<a9a5a663-91d4-b8bc-7502-6e9520a0763f@redhat.com>
	<20160617151900.GE18662@thinpad.lan.raisama.net>
	<deb30133-e84e-2c09-cc22-b34d1e9f3d90@redhat.com>
	<20160617154905.GH18662@thinpad.lan.raisama.net>
	<20160621194440.GN17952@thinpad.lan.raisama.net>
	<9b76415a-23e6-3ded-4dbc-42838cc164b0@redhat.com>
	<20160622142414.GI30202@redhat.com>
	<ef002b40-712a-00e8-a30a-00057929a56f@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ef002b40-712a-00e8-a30a-00057929a56f@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>, Marcel Apfelbaum <marcel@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, qemu-devel@nongnu.org

On Wed, Jun 22, 2016 at 04:33:18PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/06/2016 16:24, Andrea Arcangeli wrote:
> > Linux could not possibly crash instead if host phys bits > guest phys
> > bits because it will never depend on GPF triggering if the must be
> > zero bits of the guest pagetables are set. Linux won't ever try to set
> > those bits and I'd be shocked if any other OS does.
> 
> Well, KVM does.  It sets _all_ bits up to 51, not just one, but still we
> have a counterexample.

How can that crash? KVM doesn't use the host phys bits (or level1 host
phys bits), the bit to set is hardcoded up to 51 and assumed no host
would possibly fail at that.

The concern in the KVM case is for nested virt as it is for an host in
this regard.

The scenario you are concerned about only happens if the bit set is not
hardcoded to 51 but is in function of the host phys bits, which is not
what KVM does.