From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 0/4] Fix to libxl migration v2 issue blocking OSSTest Date: Tue, 21 Jul 2015 16:05:19 +0100 Message-ID: <1437491119.8383.53.camel@citrix.com> References: <1437151878-11792-1-git-send-email-andrew.cooper3@citrix.com> <20150720095639.GC12455@zion.uk.xensource.com> <55ACC950.2080806@citrix.com> <20150721124945.GR12455@zion.uk.xensource.com> <1437490290.8383.50.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1437490290.8383.50.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , Andrew Cooper Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, 2015-07-21 at 15:51 +0100, Ian Campbell wrote: > On Tue, 2015-07-21 at 13:49 +0100, Wei Liu wrote: > > On Mon, Jul 20, 2015 at 11:11:28AM +0100, Andrew Cooper wrote: > > > On 20/07/15 10:56, Wei Liu wrote: > > > > On Fri, Jul 17, 2015 at 05:51:14PM +0100, Andrew Cooper wrote: > > > > > And three improvements to debugging. > > > > > > > > > > Note that there is still a bug in libxl__toolstack_save() > > > > > which > > > > > valgrind identified, but I do not wish to block this bugfix > > > > > on > > > > > that > > > > > > > > > > Andrew Cooper (4): > > > > > tools/libxc: Identify the path of the kernel image which > > > > > cannot be > > > > > found > > > > > tools/libxl: Log the subject fd in datacopier messages > > > > > tools/libxl: Identify copywhat in stream v2 datacopiers > > > > I think all three patches should wait until next development > > > > window > > > > opens unless we have nothing else in our queue (which doesn't > > > > seem to be > > > > the case at the moment). > > > > > > You mean delay until 4.7? I disagree. Without these fixes, > > > debugging > > > issues is substantially harder than they need to be. > > > > > > They literally are only adding extra information into existing > > > error > > > messages. > > > > > > > Well I am expecting two to three big series getting applied soon, > > any > > changes that gets applied now has the chance of forcing those > > series > > to > > be rebased. > > Wei and I discussed this IRL, the concern was the outstanding colopre > patches. > > However I did a test apply on top of > https://github.com/macrosheep/xen.git#colo/colo-v9 (the latest > colopre) > and there were no rejects due to the remus refactoring. > > There were rejects because I already applied 4/4 on Friday, i.e. they > were the inverse of what I fixed up then. > > So given the lack of interaction with colopre Wei gave me permission > to > go ahead, so I have applied patches 1..3. > > 4 was applied already, of course. In doing this I managed to revert part of #4, thanks to Andy for noticing so promptly. I've pushed the following: >>From 1287ac109c44ca9b99eb642316d7af83b4081b52 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Tue, 21 Jul 2015 16:00:19 +0100 Subject: [PATCH] tools: libxl: Refix "Initialise the fd of the unused half of a datacopier" Applying the series out of order led to d72befc35f31 "tools/libxl: Identify copywhat in stream v2 datacopiers" unintentionally reverting part of 21d9b079e538 "tools/libxl: Initialise the fd of the unused half of a datacopier". Put this back. Reported-by: Andrew Cooper Signed-off-by: Ian Campbell --- tools/libxl/libxl_stream_read.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c index 3e1cd2a..32a3551 100644 --- a/tools/libxl/libxl_stream_read.c +++ b/tools/libxl/libxl_stream_read.c @@ -611,6 +611,7 @@ static void write_emulator_blob(libxl__egc *egc, dc->writewhat = "qemu save file"; dc->copywhat = "restore v2 stream"; dc->writefd = writefd; + dc->readfd = -1; dc->maxsz = -1; dc->callback = write_emulator_done; -- 2.1.4