From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFrUJ-0001tX-4z for qemu-devel@nongnu.org; Wed, 22 Jun 2016 19:23:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFrUE-0003gh-Tb for qemu-devel@nongnu.org; Wed, 22 Jun 2016 19:23:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFrUE-0003gd-NT for qemu-devel@nongnu.org; Wed, 22 Jun 2016 19:23:10 -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 1D4AB73059 for ; Wed, 22 Jun 2016 23:23:10 +0000 (UTC) Date: Thu, 23 Jun 2016 01:23:08 +0200 From: Andrea Arcangeli Message-ID: <20160622232308.GQ30202@redhat.com> 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> <20160623014216-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160623014216-mutt-send-email-mst@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: "Michael S. Tsirkin" Cc: Paolo Bonzini , Eduardo Habkost , Marcel Apfelbaum , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org On Thu, Jun 23, 2016 at 01:44:06AM +0300, Michael S. Tsirkin wrote: > On Wed, Jun 22, 2016 at 04:24:14PM +0200, Andrea Arcangeli wrote: > > > 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. > > > > But the crash with guest phys bits > host phys bits is material, linux > > will definitely crash in such condition. > > Why would it? Most GPA addresses are not guest controllable. > Don't give guest addresses that host can't access, you will not get > a crash. > > The only exception I know of is PCI BARs but we can limit > these to a safe addressable range using _CRS method in ACPI. > > Could you explain please? Well the crash of guest phys bits > host phys bits, should be easy to reproduce by booting a 65GB guest on a 64GB RAM + 2GB swap host with 36 host phys bits using the upstream qemu that forces the guest phys bits to 40. Likely the guest won't boot properly regardless if the PCI bars are at the end, but it may have a chance to print something meaningful on the console while trying instead of failing in some unexpected way. Now the production patch fixes it 100% by using the host bits instead of value 40. However you'd run into the instability if you migrate the same guest to the aformentioned host. No amount of guest changes can fix the above. So then we can avoid any risk of breakages also during live migration introducing a "soft" guest phys bits set as low as possible. And live migration restore can check it against the host phys bits. The other case (guest phys bits < host phys bits) instead requires a guest doing something strange, definitely never going to be a problem with linux as guest at least.