From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPdi-0002HA-5f for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:39:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKPdd-0001Ul-8I for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:39:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPdd-0001UP-2l for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:39:41 -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 20513C05B1D6 for ; Tue, 5 Jul 2016 12:39:40 +0000 (UTC) Date: Tue, 5 Jul 2016 15:39:36 +0300 From: "Michael S. Tsirkin" Message-ID: <20160705153608-mutt-send-email-mst@redhat.com> References: <1467659769-15900-1-git-send-email-dgilbert@redhat.com> <20160704231009-mutt-send-email-mst@redhat.com> <20160705093324.GC2118@work-vm> <20160705130015-mutt-send-email-mst@redhat.com> <20160705140848-mutt-send-email-mst@redhat.com> <8f71b337-6c3f-bf10-3478-0619b06af8dc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f71b337-6c3f-bf10-3478-0619b06af8dc@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: marcel@redhat.com, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , ehabkost@redhat.com, kraxel@redhat.com On Tue, Jul 05, 2016 at 01:46:58PM +0200, Paolo Bonzini wrote: > > > On 05/07/2016 13:09, Michael S. Tsirkin wrote: > > > How do you handle migration in the above scenario from say 46bit host to > > > 39bit host, where the firmware has mapped (while running on the source) > > > a 64-bit BAR above the destination's maximum physical address? > > > > Again management would specify how much 64 bit pci space firmware should use. > > If more is specified than host can support we can error out. > > Ok, so the destination would fail to start. > > It sounds good, and it may provide a good reason not to enable > autodetection of phys-addr-bits for new machine types. We still want > David's patches for -cpu host, Right, but I think current patches aren't limited to -cpu host - I guess they will need some changes then? > and for improved backwards compatibility > now that KVM_SET_MSR error detection is strict. Sounds good. > Thanks, > > Paolo