From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzntJ-00065P-3q for qemu-devel@nongnu.org; Sat, 03 Sep 2011 06:56:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzntI-0000zv-2B for qemu-devel@nongnu.org; Sat, 03 Sep 2011 06:56:00 -0400 Received: from mail-qw0-f43.google.com ([209.85.216.43]:35834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzntH-0000zq-VM for qemu-devel@nongnu.org; Sat, 03 Sep 2011 06:56:00 -0400 Received: by qwm42 with SMTP id 42so2604692qwm.30 for ; Sat, 03 Sep 2011 03:55:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <4E5DF31A.1@redhat.com> From: Blue Swirl Date: Sat, 3 Sep 2011 10:55:39 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH, RFC] trace: implement guest tracepoint passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dhaval Giani Cc: qemu-devel , Glauber Costa , =?UTF-8?B?TGx1w61z?= , Avi Kivity , Stefan Hajnoczi On Sat, Sep 3, 2011 at 9:26 AM, Dhaval Giani wrote= : > On Sat, Sep 3, 2011 at 1:53 AM, Blue Swirl wrote: >> On Wed, Aug 31, 2011 at 6:00 PM, Dhaval Giani w= rote: >>> On Wed, Aug 31, 2011 at 10:58 AM, Blue Swirl wro= te: >>>> On Wed, Aug 31, 2011 at 8:38 AM, Avi Kivity wrote: >>>>> On 08/26/2011 10:06 PM, Blue Swirl wrote: >>>>>> >>>>>> Let guests inject tracepoint data via fw_cfg device. >>>>>> >>>>>> >>>>> >>>>> At least on x86, fw_cfg is pretty slow, involving multiple exits. =C2= =A0IMO, for >>>>> kvm, even one exit per tracepoint is too high. =C2=A0We need to use a= shared >>>>> memory transport with a way to order guest/host events later on (by u= sing a >>>>> clock). >>>> >>>> This could be an easy way, if the guest always had access to an >>>> accurate clock, but that may not be the case. >>>> >>> >>> From what I understand, kvmclock should be good enoguh for this >>> purpose. That is what I am using. >> >> It's only available for KVM on x86, that is most certainly not enough. >> > > From what I understood it is available on other architectures as well, > but let us just confirm with glommer. This line in Makefile.target limits the device to KVM on x86: obj-i386-$(CONFIG_KVM) +=3D kvmclock.o Moreover, the code assumes that CPUState structure contains a field cpuid_kvm_features but that is only available on x86. Perhaps the device can be made generic but I don't see how it should work with TCG. Actually I don't understand it at all, I think key functionality must be inside KVM module.