From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USpLX-0005Nw-EO for qemu-devel@nongnu.org; Thu, 18 Apr 2013 09:57:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USpLU-0004lV-Dc for qemu-devel@nongnu.org; Thu, 18 Apr 2013 09:57:55 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:55398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USpLU-0004lO-6m for qemu-devel@nongnu.org; Thu, 18 Apr 2013 09:57:52 -0400 Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Apr 2013 07:57:50 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 795193E4004F for ; Thu, 18 Apr 2013 07:57:28 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3IDvd5W384892 for ; Thu, 18 Apr 2013 07:57:39 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3IE0TbO029441 for ; Thu, 18 Apr 2013 08:00:29 -0600 Message-ID: <516FFBD2.8010705@linux.vnet.ibm.com> Date: Thu, 18 Apr 2013 09:57:38 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1366240040-10730-1-git-send-email-mrhines@linux.vnet.ibm.com> <1366240040-10730-9-git-send-email-mrhines@linux.vnet.ibm.com> <516FA6D5.8010307@redhat.com> In-Reply-To: <516FA6D5.8010307@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL v4 08/11] rdma: core logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, quintela@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com On 04/18/2013 03:55 AM, Paolo Bonzini wrote: > The reason is that when using a management layer stderr will be logged > but not printed to the operator's console. Instead, Errors are sent on > the monitor connection. The management layer(s) then pick up the error > and propagate it through the various APIs until they appear in the > terminal/browser/whatever. The incoming migration is done through "qemu_set_fd_handler2", which does not pass an error pointer, after "rdma_accept_incoming_migration()". How exactly would you propagate destination errors through the monitor without an error pointer?