From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPfs-0005az-6p for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:42:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKPfm-00028Y-NR for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:41:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKPfm-00028P-He for qemu-devel@nongnu.org; Tue, 05 Jul 2016 08:41:54 -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 203AADF220 for ; Tue, 5 Jul 2016 12:41:54 +0000 (UTC) Date: Tue, 5 Jul 2016 13:41:50 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160705124149.GK2118@work-vm> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160705140848-mutt-send-email-mst@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: "Michael S. Tsirkin" Cc: Paolo Bonzini , marcel@redhat.com, kraxel@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com * Michael S. Tsirkin (mst@redhat.com) wrote: > On Tue, Jul 05, 2016 at 12:59:42PM +0200, Paolo Bonzini wrote: > > > > > > On 05/07/2016 12:06, Michael S. Tsirkin wrote: > > > > -m 2G,slots=16,maxmem=2T > > > > > > > > On a host with a 39bit physaddress limit do you error > > > > on that or not? I think oVirt is currently doing something > > > > similar to that, but I'm trying to get confirmation. > > > > > > That would only be a problem since pci is allocated above > > > maxmem so 64 bit pci addresses aren't accessible. > > > With my proposal we can actually force firmware to avoid > > > using 64 bit memory for that config. > > > Will work better than today. > > > > So you would remove completely the 64-bit _CRS in this case? > > Yes. > > > 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? > > > > Thanks, > > > > Paolo > > 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. What stops the guest OS mapping PCI stuff high up - however much you change the firmware? Dave > > -- > MST -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK