Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 11/12] md: convert cpu notifier to return encapsulate errno value
Next: [GIT PULL] vhost-net fixes for issues in 2.6.34-rc1
From: Andi Kleen on 24 Mar 2010 01:20 Joerg Roedel <joro(a)8bytes.org> writes: > > Sidenote: I really think we should come to a conclusion about the > concept. KVM integration into perf is very useful feature to > analyze virtualization workloads. Agreed. I especially would like to see instruction/branch tracing working this way. This would a lot of the benefits of a simulator on a real CPU. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 24 Mar 2010 03:40 > If you're profiling a single guest it makes more sense to do this from > inside the guest - you can profile userspace as well as the kernel. I'm interested in debugging the guest without guest cooperation. In many cases qemu's new gdb stub works for that, but in some cases I would prefer instruction/branch traces over standard gdb style debugging. I used to use that very successfully with simulators in the past for some hard bugs. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 24 Mar 2010 05:40 Avi Kivity <avi(a)redhat.com> writes: > On 03/24/2010 09:38 AM, Andi Kleen wrote: >>> If you're profiling a single guest it makes more sense to do this from >>> inside the guest - you can profile userspace as well as the kernel. >>> >> I'm interested in debugging the guest without guest cooperation. >> >> In many cases qemu's new gdb stub works for that, but in some cases >> I would prefer instruction/branch traces over standard gdb style >> debugging. >> > > Isn't gdb supposed to be able to use branch traces? AFAIK not. The ptrace interface is only used by idb I believe. I might be wrong on that. Not sure if there is even a remote protocol command for branch traces either. There's a concept of "tracepoints" in the protocol, but it doesn't quite match at. > It makes sense to > expose them via the gdb stub then. Not to say an external tool > doesn't make sense. Ok that would work for me too. As long as I can set start/stop triggers and pipe the log somewhere it's fine for me. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel P. Berrange on 24 Mar 2010 11:30
On Wed, Mar 24, 2010 at 04:01:37PM +0100, Joerg Roedel wrote: > >> An approach like: "The files are owned and only readable by the same > >> user that started the vm." might be a good start. So a user can measure > >> its own guests and root can measure all of them. > > > > That's not how sVirt works. sVirt isolates a user's VMs from each > > other, so if a guest breaks into qemu it can't break into other guests > > owned by the same user. > > If a vm breaks into qemu it can access the host file system which is the > bigger problem. In this case there is no isolation anymore. From that > context it can even kill other VMs of the same user independent of a > hypothetical /sys/kvm/. No it can't. With sVirt every single VM has a custom security label and the policy only allows it access to disks / files with a matching label, and prevents it attacking any other VMs or processes on the host. THis confines the scope of any exploit in QEMU to those resources the admin has explicitly assigned to the guest. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |