From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFjSd-0002gF-O3 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:49:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFjSZ-0002ov-J8 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:48:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFjSZ-0002oP-DA for qemu-devel@nongnu.org; Wed, 22 Jun 2016 10:48:55 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 D7B6E7F6A8 for ; Wed, 22 Jun 2016 14:48:54 +0000 (UTC) References: <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> <20160622142414.GI30202@redhat.com> <20160622144410.GL30202@redhat.com> From: Paolo Bonzini Message-ID: <21a5ea2e-e83b-a874-8992-9e5bde710840@redhat.com> Date: Wed, 22 Jun 2016 16:48:50 +0200 MIME-Version: 1.0 In-Reply-To: <20160622144410.GL30202@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Andrea Arcangeli Cc: Eduardo Habkost , Marcel Apfelbaum , "Michael S. Tsirkin" , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org On 22/06/2016 16:44, Andrea Arcangeli wrote: > 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. KVM encodes other information in the sPTE when it sets the reserved bit (a generation count). Instead of using all bits up to 51, KVM could well use bit MAXPHYADDR+1 as a marker and add bits MAXPHYADDR+2...51 to the generation count. You cannot really rely on what the guest does, no matter how crazy it seems. Paolo