From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNkDS-0008V9-HY for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:38:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNkDS-0008Tx-2P for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:38:10 -0500 Received: from [199.232.76.173] (port=34424 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNkDR-0008Ti-Ma for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:38:09 -0500 Received: from mx20.gnu.org ([199.232.41.8]:1087) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LNkDR-0004Ch-2B for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:38:09 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNkDQ-0002QP-8R for qemu-devel@nongnu.org; Fri, 16 Jan 2009 03:38:08 -0500 Message-ID: <4970476C.8050804@web.de> Date: Fri, 16 Jan 2009 09:38:04 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support References: <496DFA33.2020606@siemens.com> <496F9D75.4020802@codemonkey.ws> <496FAA5D.3000403@web.de> <200901160015.44729.paul@codesourcery.com> <49703FAD.1060107@web.de> In-Reply-To: <49703FAD.1060107@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8471376F6D2B71710CBE5CD0" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8471376F6D2B71710CBE5CD0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Paul Brook wrote: >>> a) Modeling cpus as processes buys us nothing compared to threads gi= ven >>> the fact that we cannot provide a stable memory mapping to the gd= b >>> frontend anyway. (*) >> I disagree. The process model fits perfectly. The whole point is that = each CPU=20 >> has its own virtual address space. Separate address spaces is the fund= amental=20 >> difference between a process and a thread. >> >> If you have a multicore system where several cores share a MMU[1] then= =20 >> modelling these as threads probably make sense. >> >> Don't confuse this with OS awareness in GDB (i.e. implementing a users= pace=20 >> debug environment via a bare metal kernel level debug interface). That= 's a=20 >> completely separate issue. >=20 > You snipped away my argument under (*): >=20 >> (*) Process abstraction is, if used at all, guest business. At best we= >> could try to invent (likely OS-specific) heuristics to identify >> identical mappings and call them processes. I don't see a reasonable >> benefit compared to the expected effort and unreliability. >=20 > You cannot simply assign some CPU n to a virtual process n because the > mapping you see on that CPU at some point in time may next pop up on > some other CPU - and vice versa. You start to make gdb believe it sees > consistent processes while you have no clue at all about the scheduling= > of your guest. So what do you gain? >=20 > I can tell you what you loose: If gdb starts to think that there are n > separate processes, you will have to set separate breakpoints as well. > Bad. And if some breakpoint assigned to process n suddenly hits you on > process (CPU) m, only chaos is the result. E.g. kvm would re-inject it > as guest-originated. Even worse. >=20 >>> b) The model is already part of mainline qemu. This patch is just >>> about adding even more usefulness to it. >> I have no problems with ripping out the bogus "thread" support once (o= r even=20 >> before) proper process support is implemented. Likewise I've no probl= em=20 >> requiring a recent GDB if you want to do multicore debugging. >=20 > There was zero practical need for this so far. But maybe you can > describe a _concrete_ debugging use case and the related steps in gdb -= > based on a potential process interface. I'm surely willing to learn > about it if there is really such a great practical improvement feasible= =2E > What will be the user's benefit? Maybe, if there are OSes in the field where a process model fits (surely not Linux), we could find the compromise to add alternative support for that model and let the user decide which one to use via some command line switch or maintenance command. There are still a few 'ifs' for me in this equation, including that gdb properly supports the model. But if they can be removed, I'm surely open for such enhancements! For now I would be very glad if we could agree on completing the thread model implementation so that users can benefit from it without having to patch qemu or kvm. Jan --------------enig8471376F6D2B71710CBE5CD0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklwR28ACgkQniDOoMHTA+k8TwCfUZdrRRnR5+CQNsMPPzVqnBd7 0REAnRUV/JgoEvWRwycGfavxVWTPJS1a =CGrx -----END PGP SIGNATURE----- --------------enig8471376F6D2B71710CBE5CD0--