From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baN6U-00072j-9n for qemu-devel@nongnu.org; Thu, 18 Aug 2016 09:11:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baN6T-0002uY-4I for qemu-devel@nongnu.org; Thu, 18 Aug 2016 09:11:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baN6S-0002uS-Un for qemu-devel@nongnu.org; Thu, 18 Aug 2016 09:11:25 -0400 Date: Thu, 18 Aug 2016 14:11:21 +0100 From: "Daniel P. Berrange" Message-ID: <20160818131121.GE13050@redhat.com> Reply-To: "Daniel P. Berrange" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] errno 13, fopen qemu trace file. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nir Levy Cc: "qemu-devel@nongnu.org" , Stefan Hajnoczi On Thu, Aug 18, 2016 at 12:58:29PM +0000, Nir Levy wrote: > Hello everybody, > > I have a progress in tracing qemu, > I add the thread and tag done for each kvm_ioctl, kvm_vm_ioctl, kvm_vcpu_ioctl > in purpose of investigating pure hypervisor activity and delays on host. > the kvm type print only for convenience. > > for example: > kvm_ioctl 3106435.230545 pid=11347 thread=11347 type=0xae03 arg=0x25 > kvm_ioctl_done 3106435.230546 pid=11347 thread=11347 type=0xae03 arg=0x25 diff=1 (KVM_CHECK_EXTENSION) > kvm_vcpu_ioctl 3106435.253930 pid=11347 thread=11354 cpu_index=0x2 type=0x4008ae9c arg=0x56417e6cb4f0 > kvm_vcpu_ioctl_done 3106435.253931 pid=11347 thread=11354 cpu_index=0x2 type=0x4008ae9c arg=0x56417e6cb4f0 diff=1 (KVM_X86_SETUP_MCE) > > kvm_vm_ioctl 3106435.268896 pid=11347 thread=11347 type=0x4020ae46 arg=0x7ffed97cf9d0 > kvm_vm_ioctl_done 3106435.269082 pid=11347 thread=11347 type=0x4020ae46 arg=0x7ffed97cf9d0 diff=186 (KVM_SET_USER_MEMORY_REGION) > > I have notice KVM_RUN can take even seconds but that is probably low priority tasks,(io workers probably) > but this 186micro second on the main qemu thread is suspicious and might cause application running over vm delays. > > however when I have switch back to installed libvirtd 1.2.13.2 > ( my version has extended timeout for qemu debugging - ver 1.2.21) > > > void st_set_trace_file_enabled(bool enable) > { > ... > trace_fp = fopen(trace_file_name, "wb"); > > trace_fp returns null and errno is 13 access denied. > In my installation I did not create cgroup, > > If you have some hint for this issue it will be great. Libvirt doesn't support use of the simpletrace backend. The security policy will prevent simpletrace from even creating its output file. It is recommended to use a dynamic trace backend like dtrace/systemtap/ ltt-ust so that QEMU does not need to directly create trace output files itself. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|