From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKOom-0003XX-JE for qemu-devel@nongnu.org; Tue, 05 Jul 2016 07:47:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKOog-0005Vk-Gy for qemu-devel@nongnu.org; Tue, 05 Jul 2016 07:47:07 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:35650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKOog-0005Ve-9c for qemu-devel@nongnu.org; Tue, 05 Jul 2016 07:47:02 -0400 Received: by mail-wm0-x22f.google.com with SMTP id z126so72178374wme.0 for ; Tue, 05 Jul 2016 04:47:02 -0700 (PDT) Sender: Paolo Bonzini 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> From: Paolo Bonzini Message-ID: <8f71b337-6c3f-bf10-3478-0619b06af8dc@redhat.com> Date: Tue, 5 Jul 2016 13:46:58 +0200 MIME-Version: 1.0 In-Reply-To: <20160705140848-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: marcel@redhat.com, qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , ehabkost@redhat.com, kraxel@redhat.com 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, and for improved backwards compatibility now that KVM_SET_MSR error detection is strict. Thanks, Paolo