From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Planning for the 0.11.0 release Date: Fri, 10 Jul 2009 12:03:33 -0500 Message-ID: <4A577465.1050104@us.ibm.com> References: <4A401A65.3080804@us.ibm.com> <1247128021.22231.1.camel@blaa> <4A55F150.3020803@codemonkey.ws> <87eisp1gx2.fsf@pike.pond.sub.org> <4A5747E4.3030101@us.ibm.com> <4A57586B.9050900@siemens.com> <4A576317.6010000@us.ibm.com> <4A576AF6.6080307@siemens.com> <4A576D49.40809@us.ibm.com> <4A5771C3.7050103@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , Mark McLoughlin , "qemu-devel@nongnu.org" , kvm-devel , Paul Brook To: Jan Kiszka Return-path: Received: from e6.ny.us.ibm.com ([32.97.182.146]:49635 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754076AbZGJREz (ORCPT ); Fri, 10 Jul 2009 13:04:55 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6AH8B4n026295 for ; Fri, 10 Jul 2009 13:08:11 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6AH3bDq214064 for ; Fri, 10 Jul 2009 13:03:37 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6AH3aTX013122 for ; Fri, 10 Jul 2009 13:03:37 -0400 In-Reply-To: <4A5771C3.7050103@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Something went wrong during transmission, and I missed that. Just sent > out those two as well. > Thanks, it's now all in staging. > That's nothing those patches changes (it's our current and only > debugging model for SMP until gdb provides a complete solution). > It Paul agrees, I'll pull it. But my understanding from the previous threads and posts was that Paul did not want to implement vCont even as a stop-gap and that he preferred to fix gdb properly. > The recent discussion went around how to deal with some other gdb > limitation: debugging targets that run in x86's 16/32 bit mode vs. the > target arch being advertised as 64 bit. Existing qemu code doesn't work > with existing gdb in this scenario, and the question was how to deal > with it until gdb is improved. > Right, that part I'm okay with. But the vCont based gdb model presumes a unified address space which while usually true for kernel address spaces, isn't universally true and certainly not true when PC is in userspace. That's what I understood to be the major objection to vCont. >> I'm not qualified to >> appreciate the difference so I'm inclined to side with Paul. Am I >> missing something there? >> > > I interpreted [1] as that the rest is OK for Paul. > Paul, can you clarify? -- Regards, Anthony Liguori