From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [Qemu-ppc] [PATCH 4/4] kvm: i386: Add classic PCI device assignment Date: Sat, 8 Sep 2012 16:59:12 +0200 Message-ID: <1D64CB98-4FAA-4DEB-BF6F-0F8AF39217BB@suse.de> References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503B62F4.9070500@suse.de> <87k3wjyy0e.fsf@codemonkey.ws> <503E227B.40904@suse.de> <874nndmrjs.fsf@codemonkey.ws> <50476F3E.7000100@redhat.com> <87wr081nq4.fsf@codemonkey.ws> <50486270.9020504@redhat.com> <82563D1C-0B5E-432B-9CA1-68F72B122055@suse.de> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "kvm@vger.kernel.org" , "Michael S. Tsirkin" , Marcelo Tosatti , "qemu-devel@nongnu.org" , Alex Williamson , Jan Kiszka , Avi Kivity , Anthony Liguori , qemu-ppc , =?utf-8?Q?Andreas_F=C3=A4rber?= To: Blue Swirl Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 08.09.2012, at 14:30, Blue Swirl wrote: > On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf wrote: >>=20 >>=20 >> On 08.09.2012, at 12:16, Blue Swirl wrote: >>=20 >>> On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf wrote: >>>>=20 >>>>=20 >>>> On 08.09.2012, at 10:06, Blue Swirl wrote: >>>>=20 >>>>> On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity wrote: >>>>>> On 09/05/2012 10:04 PM, Blue Swirl wrote: >>>>>>>=20 >>>>>>> Reinventing a disassembler for ever growing x86 assembly is >>>>>>> no fun. >>>>>>=20 >>>>>> We can try linking to a disassembler library. I use udis86 to >>>>>> disassemble instructions in kvm tracepoints >>>>>> (http://udis86.git.sourceforge.net/git/gitweb.cgi?p=3Dudis86/udis86;a= =3Dshortlog), >>>>>> it's maintained but not heavily so. >>>>>=20 >>>>> I think commonality with KVM would be preferred. The library looks >>>>> neat and based on changelog, more actively developed than BSD DDB. >>>>>=20 >>>>>>=20 >>>>>> Of course for non-x86 we'd need to continue using binutils; this is >>>>>> about copying code vs. libraries, not about licensing. >>>>>=20 >>>>> For most architectures, pre-GPLv3 binutils is good enough since the >>>>> instruction set does not change anymore. Maybe only PPC and Sparc64 >>>>> still change besides x86. New CPUs types more recent than 2007 will >>>>> have problems. >>>>=20 >>>> Alternatively we could try to run the disassembler in a different proce= ss, right? >>>=20 >>> For qemu.log this would be doable and even improve performance since >>> only binary data would be transferred. >>>=20 >>> But for monitor disassembly command x/i it may be too clumsy. >>=20 >> Why would it be clumsy? We'd have to make sure we are communicating synch= ronously with the daemon, but apart from that it shouldn't be too different f= rom the log, no? >=20 > The log file should be written as binary which the disassembly tool > could read. The log file contains a lot more information than just the diassembly. You g= et cpu state dumps, tcg op dumps, and above all there are a very big amount o= f log writing bits throughout the code for debug purposes that write plain a= scii. Do you think it's worth creating a 2-step process out of this? I was more th= inking along the lines of a second process that qemu would spawn when log fi= le is active / on monitor command which then would get binary opcodes voa a p= ipe and returns ascii disassembly that qemu cam use again. That second program could even be built as part of our build process, right?= We would then be able to pull in gplv3 code from binutils into that program= , but keep it out of the main project. Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TAMVO-00014m-1u for qemu-devel@nongnu.org; Sat, 08 Sep 2012 10:59:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TAMVM-0001Ld-Nq for qemu-devel@nongnu.org; Sat, 08 Sep 2012 10:59:29 -0400 References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503B62F4.9070500@suse.de> <87k3wjyy0e.fsf@codemonkey.ws> <503E227B.40904@suse.de> <874nndmrjs.fsf@codemonkey.ws> <50476F3E.7000100@redhat.com> <87wr081nq4.fsf@codemonkey.ws> <50486270.9020504@redhat.com> <82563D1C-0B5E-432B-9CA1-68F72B122055@suse.de> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1D64CB98-4FAA-4DEB-BF6F-0F8AF39217BB@suse.de> From: Alexander Graf Date: Sat, 8 Sep 2012 16:59:12 +0200 Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 4/4] kvm: i386: Add classic PCI device assignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: "kvm@vger.kernel.org" , "Michael S. Tsirkin" , Marcelo Tosatti , "qemu-devel@nongnu.org" , Alex Williamson , Jan Kiszka , Avi Kivity , Anthony Liguori , qemu-ppc , =?utf-8?Q?Andreas_F=C3=A4rber?= On 08.09.2012, at 14:30, Blue Swirl wrote: > On Sat, Sep 8, 2012 at 12:13 PM, Alexander Graf wrote: >>=20 >>=20 >> On 08.09.2012, at 12:16, Blue Swirl wrote: >>=20 >>> On Sat, Sep 8, 2012 at 9:28 AM, Alexander Graf wrote: >>>>=20 >>>>=20 >>>> On 08.09.2012, at 10:06, Blue Swirl wrote: >>>>=20 >>>>> On Thu, Sep 6, 2012 at 8:44 AM, Avi Kivity wrote: >>>>>> On 09/05/2012 10:04 PM, Blue Swirl wrote: >>>>>>>=20 >>>>>>> Reinventing a disassembler for ever growing x86 assembly is >>>>>>> no fun. >>>>>>=20 >>>>>> We can try linking to a disassembler library. I use udis86 to >>>>>> disassemble instructions in kvm tracepoints >>>>>> (http://udis86.git.sourceforge.net/git/gitweb.cgi?p=3Dudis86/udis86;a= =3Dshortlog), >>>>>> it's maintained but not heavily so. >>>>>=20 >>>>> I think commonality with KVM would be preferred. The library looks >>>>> neat and based on changelog, more actively developed than BSD DDB. >>>>>=20 >>>>>>=20 >>>>>> Of course for non-x86 we'd need to continue using binutils; this is >>>>>> about copying code vs. libraries, not about licensing. >>>>>=20 >>>>> For most architectures, pre-GPLv3 binutils is good enough since the >>>>> instruction set does not change anymore. Maybe only PPC and Sparc64 >>>>> still change besides x86. New CPUs types more recent than 2007 will >>>>> have problems. >>>>=20 >>>> Alternatively we could try to run the disassembler in a different proce= ss, right? >>>=20 >>> For qemu.log this would be doable and even improve performance since >>> only binary data would be transferred. >>>=20 >>> But for monitor disassembly command x/i it may be too clumsy. >>=20 >> Why would it be clumsy? We'd have to make sure we are communicating synch= ronously with the daemon, but apart from that it shouldn't be too different f= rom the log, no? >=20 > The log file should be written as binary which the disassembly tool > could read. The log file contains a lot more information than just the diassembly. You g= et cpu state dumps, tcg op dumps, and above all there are a very big amount o= f log writing bits throughout the code for debug purposes that write plain a= scii. Do you think it's worth creating a 2-step process out of this? I was more th= inking along the lines of a second process that qemu would spawn when log fi= le is active / on monitor command which then would get binary opcodes voa a p= ipe and returns ascii disassembly that qemu cam use again. That second program could even be built as part of our build process, right?= We would then be able to pull in gplv3 code from binutils into that program= , but keep it out of the main project. Alex