From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzgX-0003rf-Aj for qemu-devel@nongnu.org; Thu, 10 Sep 2015 07:06:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZzgS-0001nQ-V5 for qemu-devel@nongnu.org; Thu, 10 Sep 2015 07:06:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzJK-0000tK-4z for qemu-devel@nongnu.org; Thu, 10 Sep 2015 06:42:34 -0400 Date: Thu, 10 Sep 2015 13:42:31 +0300 From: "Michael S. Tsirkin" Message-ID: <20150910134121-mutt-send-email-mst@redhat.com> References: <1441626932-76366-1-git-send-email-imammedo@redhat.com> <1441626932-76366-2-git-send-email-imammedo@redhat.com> <20150909200356.GA11100@thinpad.lan.raisama.net> <20150910115907.2112265e@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910115907.2112265e@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/2] pc: memhotplug: fix incorrectly set reserved-memory-end List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: bharata@linux.vnet.ibm.com, Eduardo Habkost , qemu-devel@nongnu.org On Thu, Sep 10, 2015 at 11:59:07AM +0200, Igor Mammedov wrote: > On Wed, 9 Sep 2015 17:03:56 -0300 > Eduardo Habkost wrote: > > > On Mon, Sep 07, 2015 at 01:55:31PM +0200, Igor Mammedov wrote: > > > reserved-memory-end tells firmware address from which > > > it could start treating memory as PCI address space > > > and map PCI BARs after it to avoid collisions with > > > RAM. > > > Currently it is incorrectly pointing to address where > > > hotplugged memory range starts which could redirect > > > hotplugged RAM accesses to PCI BARs when firmware > > > maps them over RAM or viceverse. > > > Fix this by pointing reserved-memory-end to the end > > > of memory hotplug area. > > > > > > Signed-off-by: Igor Mammedov > > > > Reviewed-by: Eduardo Habkost > > > > But I would like to see this squashed into patch 2/2 (or the rebased > > version of patch 2/2) to keep bisectability. > > Eduardo, thanks for review. > It's ok squash 2/2, could you handle it and take it through your tree? I merged them separately already: I'm not too concerned about breaking cross version migration being slightly racy when doing bisect. -- MST