From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNm8-0008G0-Hi for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:52:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuNm5-0003pJ-S6 for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:52:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNm5-0003p7-Mo for qemu-devel@nongnu.org; Thu, 05 Nov 2015 11:52:33 -0500 References: <1432324792-9373-1-git-send-email-jsnow@redhat.com> <1432324792-9373-8-git-send-email-jsnow@redhat.com> From: John Snow Message-ID: <563B894F.20609@redhat.com> Date: Thu, 5 Nov 2015 11:52:31 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 07/19] qtest/ahci: Add migration test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 11/05/2015 10:26 AM, Peter Maydell wrote: > On 22 May 2015 at 20:59, John Snow wrote: >> Notes: >> >> * The migration is performed on QOSState objects. >> >> * The migration is performed in such a way that it does not assume >> consistency between the allocators attached to each. That is to say, >> you can use each QOSState object completely independently and then at >> an arbitrary point decide to migrate, and the destination object will >> now be consistent with the memory within the source guest. The source >> object that was migrated from will have a completely blank allocator. > >> +static void test_migrate_sanity(void) >> +{ >> + AHCIQState *src, *dst; >> + const char *uri = "tcp:127.0.0.1:1234"; > > Hi. I've just noticed that these migration tests are hardcoded > to port 1234. The reason I noticed is that this is also the default > port used for the gdbstub if you use QEMU's "-s" argument, so > a 'make check' running in a completely different QEMU tree failed > because I happened to be running a QEMU with the gdbstub at the > same time. > > Could we at least switch to a different port number, please? > (Ideally we would want to be able to pick a port such that > you could do 'make check' in two different qemu trees without > them interfering with each other, but that's harder.) > > thanks > -- PMM > I'll just have it use something that isn't TCP instead, since it's not really vital to the test. --js